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(54) Computer t>ased graphical user interface for processing audio and video data and method 
of processing audio and video data 



(57) A system and method for displaying a user 
Interface in the fonm of a program guide that assists 
users in determining and sdecting television viewing 
options and related services is described. The gukle is 
a viewable display constructed at receiver stations 
based on data periodically received via a Direct-to- 
Home (DTH) satellite communication or other system. 
Preferably, the data decoder of the receiver station is a 
personal computer or a device having similar process- 
ing power. The guide cSsplay pres^rtation can include 
still pictures, live video broadcasts, still graphics, mov- 
ing graphics, webpages, graphics and "buttons" that are 
utilized by the viewer to perform a variety of operations, 
includir^ determining program availability, selecting 
programming or services, and launching to related infor- 
mation, programming or s^vk;es. A tuning bar Is auto- 
matically scaled to seamlessly represent all programs 
that a given user subscraaes to. The user moves a 
graphic slider along the tuning bar to quickly and intui- 
tively select a current program. A pop-up graphic 
remote control presents a context adapted graphic sim- 
ulation and associated functionality. The guide includes 
a remote that is adaptive to the pontext that launches it 
and which may be customized to simulate the appear- 
ance of a particular manufacturer's remote control unit 
The system further provides a senoce that provides 



access to Intemet wet>site infonnation through data 
obtained from a satellite transmission, from transmis- 
sions across the Internet, and from locally cached infor- 
n^tion. The guide display layout and organization is 
ddined by one or more records that are broadcast as 
part of the broadcast streaming data. The user inter- 
nee, according to the present invention, is constructed 
from both real time broadcast data f streaming" data) 
and periodically downloaded and stored data ("file" 
data). 
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Description 

L BACKGROUND OF THE IISIVENTiQM 

A-QfiU^UhaJnygnfiOQ s 

[0001] The present invention relates in general to 
entertainment broadcast systenos that transmit and 
receive a wide variety of video, audio, software and 
other types of data. More particularly, it relates to a io 
mutti-channel broadcast system that transmits a 
video/lext/graphic-based program guide data stream 
that is used at viewer stations to generate a user inter* 
foce that fadlitates a user's selection of various pro- 
grams and services. is 

B. Description of Related Art 

[Gu#2] Vhe use ol eiectronic communications media 
to provide access to large anrx)unts of video, aucfia tex- so 
tual and data information is becon^ng more frequent 
For example, ttie public etched telephone network 
(PSTN) is routinely used to transmit low speed digital 
data to and from personal computers. Cable television 
infrastructure is used to carry, via coaxial cat)le, analog zs 
or digital cable television signals, and may also be used 
to provkie high speed Internet connections. In general, 
cable television infrastructures include many head ertd 
or transmission stations that receive programming from 
a variety of sources, then distiibute ttie programming to 30 
local subscribers via a coaxial cable network. Large 
Direct-to-Home (DTH) satellite communications sys- 
tems transmit directly to viewers over one hundred fifty 
audio and video channels, along with very high speed 
data. DTH systems typically include a tansmission sta- 35 
tion that tiBnsmits audio. >^deo and data to subscriber 
stations, via satellite. 

[0003] One particularly advantageous DTH satellite 
system is the digital satellite television distribution sys- 
tem utilized by the DIRECTV® broadcast service. This 40 
system transports digital data, digital video and digital 
audio to a viewer's home via high-powered Ku^and sat- 
ellites. The various program providers send program- 
ming material to transmission stations. If the 
programming is received in analog form, it is converted 45 
to digital. The transmission stations compress the digital 
vkleo/audio programming (if needed), encrypt the video 
and/or audio, and format the information into data 
'Vpackets" that are multiplexed with other data (e.g.. 
electronic program guide data) into a plurality of bit- so 
streams, which include identifyir^g headers. Each pack- 
etized bitstream is modulated on a carrio- and 
transmitted to a satellite, where it is relayed back to 
earth and received and decoded by tiie viewer's 
receiver station. The receiver station includes a satellite 55 
antenna and an integrated receiver/decoder (IRD). The 
IRD may be connected to appropriate output devices, 
typically including a video display 



[0004] In general, DTH satellite(s) broadcast on 
several frequencies from multiple transponders at differ- 
ing polarizations (e.g., left and right hand circular polar- 
ization), and each transponder bitstream includes ttie 
video and audio data packets (m a conpressed fonnat) 
for several different programs (or Viewer channels"). 
For example, transponder ONE may broadcast the dig- 
ital video and audio data packets tor ESPN. TNT. AMC. 
A&E. El, STARZ and USA. in a statistically multiplexed 
fashion. SateOites or other distnlxition systems which 
require separate input processing (e.g.. satellites at two 
separated locations requiring different antennas) may 
also be used. Accordingly, in order to receive a desired 
viewer channel, the receiver station must know the 
transponder frequency and the potarization at whk:h the 
desired signal information is being broadcast by the sat- 
eflite. along with tiie kientifying header information for 
tiiose data packets on ttiat transponder that relate to the 
JcSired progTara to pmalt ite isolation frcm the rriultj- 
ptexed bitstream. 

[0005] Each satellite transponder broadcasts a pro- 
gram guide data stream, which typically includes fK)t 
only broadcast schedule data, but also the aforemen- 
tioned infonTiation ttiat the receiver station needs in 
order to tune to a particular channel. The program ^ide 
data stream is broadcast on all sateOite ti-ansponders so 
that channel selection information is always available to 
the IRD regardless of ttie channel to which ttie IRD is 
tuned 

[0006] The data packets are di^nguished from one 
another by ttieir header information, which is referred to 
as ttie packet's "service channel ID" (SCID). For exam- 
ple, if a viewer instructs the IRD to display ESPN, ttte 
IRD, via the tuning information in the program gukle 
data stream, determines flie transponder frequency and 
polarization at which ttie ESPN programming is broad- 
cast, along witti the SCIDs of ttie data packets that are 
needed to generate and display ttie video, aucfio, and 
data comem of the ESPN program. 
[0007] The scheduling data in ttie program guide 
data packets also provide channel and program- 
attribute infonnation ttiat is used by ttie IRD to construct 
and output as a viewat)le display (which may be a full or 
a partial screen) a text-t>ased listing of programming 
channels, times, titles, descriptions, ratings, etc. tn 
operation, a program guide display is typically pre- 
sented as a grid having channels Gsted along the left, 
times across ttie top. and program tities shown wittiin 
ttie grid squares. Users can scroll ttirough ttie grid, 
erttier up and down (by channel) or to the left and right 
(by time). Channels can be selected by inputting ttie 
channel number directiy using ttie number keys on a 
user's remote control, or channels may be selected from 
tfie program guide display by highlighting and selecting 
a currently broadcast program ttiat is listed in ttie grid. In 
eittier case, ttie IRD tunes to ttie chosen channel by 
accessing the channel's transponder (frequency), polar- 
ization, and SCID information denoted by ttie program 
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guide ddta stream. 

[0008] An extension of known IRD equtpnnent is a 
PC-based sy^em that allows users to receive, directly 
into their PCs, the same digita) videa aiKfia and related 
information signals receved in conventional DTH sys- 
tems. The receiver station in this PC-based system 
includes a local satellite receiver dish similar to that of a 
conventional IRD system, but the IRD functions are 
implemented within the PC architei^e through the use 
of one or more circuit boards that are inserted into the 
PC. TTie decoded outputs from these boards are dis- 
played on the PC's monitor, or may be output to a con- 
ventional video display (e.g.. a t^evision set) and/or 
other nass storage medium such as magnetic tape, 
digital vtieo disk (DVD), optical or magnetic disk, video 
reoord& (VCR), etc. Because the reefer station 
includes a personal computer, a large number of addi- 
tional data and software-related services can also be 
downloaded directly to the PC. thereby offering a variety 
of services, including broadcast programming, pay-per- 
view events, audio programming, data services, web- 
casting, software downloads and other data or soft- 
ware-related services. 

[0009] While known program guides have advan- 
tages, there is still room for improvement, particularly 
when considering the large number of data, software, 
videa audio, pay-per-view and other programming serv- 
ices available through present and future DTH satellite 
broadcast services. For example, the viewable display 
generated from electronic program guide data tends to 
be presented primarily as text laid out in a grid. The 
processing power of cun-ently available IRD's. while 
appropriate for cunent DTH programming services, 
inherently limits how the program guide can be dis- 
played, how much information can be incorporated into 
the guide, and how quickly and efficiently a user can 
move through the guide. These program guides are 
therefore essentially limited to conveyir^ program avail- 
ability and tuning informatiOT. and do not have the 
organization and flexibility to effectively support oth^ 
services such as software downloads, webpage Qnks 
and downloads, data services, and other functions, 
[0010] Accordingly, for broadcast systenrts having a 
large number of services that deliv^ a large anrount of 
data to relatively sophisticated receiver stations (e.g.. a 
PC), there is a need for a broadcast electronic program 
guide and an associated viewakile display format and 
content that significantly enhances how the program 
guide can be displayed, how much information can be 
incorporated into the guide, and how quickly and effi- 
ciently the user can move through the guide. 

II. SUMMARY OF THE INVEMTiON 

[0011] The present invention provides a method 
and apparatus for efficiently and effectively transmitting, 
receiving, organizing and selecting transmitted data. 
The method and apparatus of the present invention is 



preferably enrtbodied in a user interface and related data 
protocols and procedures. The user interface may be 
implemented in the context of a wireless d^bution 
system for securely. reBaUy and inexpensively dstribut- 

5 tng videa audia data service, software and other serv- 
ices to geographk^alty remote receiver stations. Ttie 
wireless distrtoution system is preferably a DTH digital 
satdlite television distrftujtion system, though other sys- 
tems (e.g.. terrestrial wire, cable, or wireless broadcast) 

70 may also be used in other enftxxliments. A typical DTH 
(figital broadcast system includes a transmission sta- 
tion, a satellite relay, and a receiver station. At the trans- 
mission station, video arKi audio programming signals 
are digitized in Uncwn manners,, multiplexed with other 

15 data signals (such as the data needed to construct a 
program guide display according to the present inven- 
tion), compressed (if required), encoded, n^ted with 
enor correction codes, nrtodu^ed on carriers, and 
uplinked to a geosynchronous satellite. The satellite 

20 receves the upBnked signals and rebroadca^ them 
over a footprint that preferably covers a predetermined 
geographical area, for example, the continental United 
States. Receiver stations, which are typcally located at 
the user's home or business, receive the satellite sig- 

25 nals. The receiver stations each include an antenna, 
which preferably is in the form of a satellite dish, along 
with an integrated receiverydecoder (IRD). The antenna 
feeds the received satellite signal to the IRD unit which 
recovers the originally transmitted digital video, audio, 

30 and data. Other receiver station equipment (e.g.. cable 
decoder units) may be used with other d^trbution sys- 
tems in other embodiments, as is well known in the art 
[001 2] The present invention is particularly applica- 
ble to a receiver station having sufficient processing 

35 power to process and generate a program guide display 
and associated features that goes beyond conventional 
video/text/grid program guides. The processing power 
may be incorporated directly imo the IRD. for example, 
by adding a more powerful microprocessor, more m&n- 

40 c^. and associated software to the conventional IRD 
circu'itry. Alternatively, the receiver station IRD may be 
replaced with a PC having circuit cards that perform the 
IRD functions. A PC-based system signiftcantiy 
increases the receiver station's processing power, along 

45 with the number of services (e.g., data services and 
software) the receiver station can receive and use. 
Accorcfingly, the features of the present invention are 
most advantageously utilized by a PC-based (or compa- 
rat^le) receiver station. 

so [001 3] A PC-based receiver station suitable for use 
with the present inv^ion includes an antenna, which 
preferably is in ttie form of a satellite dish, along with a 
PC which, like the at}Ove-described IRD. recovers the 
originaDy toBnsmitted digital video, audia and data. The 

55 digital broadcast data received from the satellite dish 
coupled directiy into a fansport circuit board within the 
PC. The PC's transport circuit board also perfonns ini- 
tial circuit functions on the signal coupled in from the 
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antenna, including tuning, denxxlutation. and forward 
error ccxrection (FEC), The transport circuit board 
wthin the PC also performs sinnilar functions to that of 
the tRD's transport circuit including channel demulti- 
plexing, decryption and access determination. The 
received digital l^roadcast data is sent from the trans- 
port drcuit to video/audio decoder circuits, which may 
be on the same or separate drcuit board. The 
video/audio decoder circuit board decompresses and/or 
decodes the received conpressed broadcast signal. 
[0014] In one embodiment of the present invention, 
the transmission station transmits to the receiver sta- 
tions program selection data/information that is used at 
each receiver station to construct an electronic program 
guide and associated display format and content (i.e., a 
user interface) that, in contrast to known videotesed 
and/or textArideo/icon-based electronic program guides, 
significantly enhances how the program guide can be 

into the guide, and how quickly and efficiently the user 
can rrme through the guide. The viewable display for- 
mat, according to the present invention, incorporates 
moving picture video, stilt pictures, text, links to external 
data sources, graphks and other features that fadlrtate 
the selection of varbus programs and services. 
[001 5] The electronic program Quide features of the 
present invention further provide a novel channel-selec- 
tion process in the fonn of a graphical representation of 
a tuning bar." The tuning bar includes a movable slider 
that shows cunrent tuning information (channel number 
and call sign) for the programming or service that is 
being shown in a main viewing area of the display. Mov- 
ing the slider (typically using a nrK)use-controlled dick 
and <tag operation) changes the tuning which changes 
what is displayed in the main viewing area. Moving a 
cursor over any portion of the bar -pops up" the chan- 
nel/call-sign assodated with that portion of the bar. The 
received data that provides tuning information to the 
tuning bar is automatically scaled to accommodate the 
mwb& of channels that are available at that station, so 
that the channels are evenly spread out along the bar 
(without gaps) regardless of the number of channels to 
whch the user sut>scribes. Also^ incremental 'up' one 
channel and 'down" one channel buttons are preferably 
provided. 

[001 6] The electronic program guide features of the 
present invention incorporate still another novel chan- 
nel-selection procedure wherein a replica of a conven- 
tional remote control unit is provkied as part of the 
display. The remote control display has graphical push- 
buttons that con-espond to those found on actual remote 
controls used for conventional stereos, video recorders, 
televisions. DTH. or caWe television systems. In embod- 
iments wherein the receiver station indudes a personal 
cornputer (PC), this feature gives the user the option of 
a 'simulated remote control' interaction that the user 
may find more comfortable than using a mouse or key- 
board alone. In an important embodiment, the button 



selections that make up the remote control display 
graphic change to fit the options available in the cun-ent 
screen, provkJing a context sensitive operation. Also, 
the receiver statton may provide a remote control ds- 
5 ptay having a shape and button layout that conresponds 
to a particular manufacturer's physical remote control. 
If. tor example, the user's televiston and other peripher- 
als are from RCA®, the system may display a remote 
control graphic having a shape and button layout that 
10 corresponds to the actual remote control for the user^ 
RCA®TV.VCRand^orlRD. 

[001 7] The electronic program gukle features of the 
pres&it Invention incorporate still another novel display 
presentation in connection with web-related services 
15 such as a "Besl-of-Web' broadcast servfce, wherein 
website data is cached at the receiver station for con- 
venient future access and/or links are provkfed for a 
real-time connection. When the user attempts to access 

so the different websites and webpages that are available. 
In additfon to the displayed list, the system maintains 
and stores a status list (or hash table) that may indude 
an indication of the medium through which the page/site 
is available and. in the case of data subject to being 

25 cached, the status of the cache fi.e.. whether or not the 
data is cached at the receiver station's memory). Mov- 
ing the cursor over one of the entries of the displayed 
table/list prompts the system to automatically search 
the informatfon in the status list and determine whether 

30 or not the page is available focally. For example, some 
webpages on the displayed list are cached in the 
receiver station*s memory, some are available through a 
future broadcast, while others can only be retrieved via 
direct access to the Internet For data that is to be 

35 cached, the user interface/display, via sqppcHling soft- 
ware, immediately checks the status list and determines 
whether that weljpage is presently cached, and gener- 
ates a pop up grafrfiic (e.g., the universal "no" symbol) 
that communicates to the user immediately whether or 

40 not that webpage is presently cached. This can be done 
in essentially real time because the receiver station 
maintains the status list of the cached webpages and 
searches that status list when the user moves the cur- 
sor over a webpage selection, without need to otherwise 

45 interrogate the system or the main system memory 
[0018] In accordance with another aspect of the 
present invention, broadcast (or %vebcast") webpages 
may be archived on a user's PC for later viewing. A web- 
cast is a constant and repeating download of spedally 

50 selected web content. The content is usually grouped 
by domain. Minimal scheduling is required for down- 
loading weticast information. Multiple groups of content 
may be identified by the same identifier, thereby aeat- 
tng a one-to-many relationship among the items of inter- 
ns est. 

[0019] As webpage information is received by the 
subscr&er unit it is stored for later use. Preferably, the 
broadcast system uses an archiving scheme based on 
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the ZIP format to group domain informatioa However, 
other aHernative archiving formats may be used so long 
as both the sender and the receiver have a common set 
If the archived files are compressed, the files are prefer- 
ably extracted or decompressed using so-called 5 
"extractor" software, an example of which is sold unda' 
the tradename PKWare"*. which is a data compression 
library (DCL) corr^tible extractor. If. however, the files 
are not compressed, any ZIP extractor may be used to 
extract and view the files. Preferably, the filenames used w 
in the webcast archive are the uniform resource iderrti- 
fier{URI). 

[0020] Webcast archive files may have a dedicated 
filename extension convention. On any given data car- 
ousel, the contents of which are r^eatedly broadcast '5 
there nuist be exactly one main file for each webcast 
This file contains a snapshot of the entire websita 
According to the present invention, update archive files 
are used to replace portions of the main f8e on the car- 
ousel. The subscriber unit stores all archive files in a 20 
subdirectory corresponding to the session ID of the 
webcast When a main file is received that is newer than 
the current main f ae in that directory all other files in that 
directory will t>e removed and any links in the proxy 
server's cache map file for this webcast will be replaced 2S 
with the URIs in the new main file. 
[0021] The invention itself, together with furtha- 
objects and attendant advantages, will best be under- 
stood by reference to the follcMnng detailed desaiption. 
taken in conjunction with the accompanying drawings. 30 

III. BRIEF DESCRIPTION OF THE DRAWINGS 

[0022] 

35 

FIG. 1 is a diagram of a direct-to-home (DTH) trans- 
mission and reception system capable of broad- 
casting and utilizing data streams embodying the 
present invention; 

FIG, 2A illustrates a representative main menu 40 
page of a graphical user interface emt)odying 
aspects of the present invention; 
FIG. 2B illustrates a graphical tuning bar in accord- 
ance with the present invention; 
FIG. 3 illustrates an exemplary page template used 45 
to generate pages underlying the main menu, in 
accordance with the present invention; 
FIG. 4 is a state diagram illustrating aspects of the 
Best-of-Web (BOW) features of the present inven- 
tion: so 
FIG. 5 illustrates an exanrple of a Best-of-Web data 
service page embodying aspects of the present 
invention: 

FIG. 6 illustrates another example of a Best-of-Web 
data s&vice page, further showing a child window 55 
emtKXIying aspects of the present invention; 
FIG. 7 illi^ates yet another example of a Best-of- 
Web data service page embodying aspects of the 



present inverrtion: 

RG. 8 is a state diagram illustrating the Software 
Downtoads features of the present invention; 
FIG. 9 tHustrates an example of a Software Down- 
loads data service page embodying aspects of the 
pr^ent invention; 

FIG. 10 is a state diagram fflustrating the Data 
Channels feahires of the present inventii^; 
Fia 11 iltu^rates an example of a data Chann^ 
service page embodying a^>ects of the present 
invention; 

Fia 12 illustrates an example of a Video Channels 
service page embodying aspects of the present 
Invention; 

FIG. 13 is a state diagram illustrating the "settings." 
"messages," and "schedule." functions of the 
present invention; 

FIG. 14 illu^tes an example of a schedule func- 
tion page embodying aspects of the present inven- 
tion; 

FIG. 15 illustrates an example of a message func- 
tion page embodying aspects of the present inven- 
tion; 

FIG. 16 illustrates an exanrple of a settings function 
page emtxxiying aspects of the present invention; 
FIG. 17 is a flow diagram r^resenting system ini- 
tialization of the tumng bar in accordance with the 
present Invention; 

RG. 18 is a flow diagram r^resenting system 
processing of a "dick" event in accc^ance with the 
present inverrtion; 

FIG. 19 is a flow diagram representing system 
processing of a "rollover" event in accordance with 
the present Invention; 

FIG. 20 is an enlarged view showing one variation 
of the pop-up remote control graphic overlay of the 
present invention; 

FIG. 21 is an enlarged view showing another varia- 
tion of the pop-up remote control graphic overlay: 
FIG. 22 is a diagram of selected hardware process- 
ing components of the receiver statk)n shown in 
FIG. 1; 

FIG. 23 is a block cEagram illustrating one possible 
system architecture within which aspects of the 
present invention nnay be used; 
FIG. 24 is a diagram illustrating a type of transport 
data packet that may be transmitted via the system 
shown in FIGS. 1 and 2; 

FIG. 25 is a block diagram iOustrating a preferred 
data flow through a protocol stack for use with the 
present invention; 

FIG. 26 is a block diagram illustrating a preferred 

method of processing a data packet for use with the 

at)ove-refererKed protocol stack; 

FIG. 27 is a representation of a BFDP header; 

FIG. 28 is a representation of a UDP header; 

FIG. 29 is a diagram of a version 4 IP packet 

header; 
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FIGS. 30A - SOD are block diagrams representing 
MPT packets; 

FIGS. 31 A and 31 B are diagrams representing a 
BARP header and a BARP address record, respec* 
tivety; and 

FIGS. 32A • 32D are sanrple SOP+ records tor var- 
ious Information services that niay be used with the 
present invention. 

IV. DESCRIPTION OF THE PREFERRED EMBODI- 
MENT 

[0023] To ^ciBtate review and undastanding of the 
Invention and the preferred embodiments, the present 
disclosure has been organized In accordance with the 
headings and sub-headings shown below. 

A. System Overview 

1 . Description of the Main Menu 

2. Description of the Page Template for Pages 
Undertying the Main Menu 

3. Description of Pages and Links Underlying 
the Main Menu 

a. Best of the Web 

b. Software Downloads 

c. Data Channels 

d. Video Channels 

e. Function Pages 

4. Tuning Interface 

a. Tuning Bar 

\x Pop-Up Remote Control 

C. Receiver Station Generally 
a Receiver Station Architecture 
E. Data Packet 
F Audio/Video Processing 

G. Data Processing 

1. Protocol Stack/Broadcast RIe Download 
Protocol (BFDP) 

2. Broadcast Address Resolution Protocol 
(BARP) 

H. SDP-f Records 

I. Webcast 

J. Conclusion 

A. System Overview 

[0024] By the way of example only, the method and 
apparatus of the present invention is disclosed in con- 
nection with a system that broadcasts, via satellite, 
video programming, data services and multimedia data 



(e.g.. webpages). ft should be understood, however, 
that any system requiring intuitive interactive program 
and/or service selection may alternatively employ the 
techniques shown herein. Such systems might include 

5 other broadcast communications techniques not tradi- 
tionally associated with video programming or the Inter- 
na. For exanrple. paging or cellular systems delivering 
news or cnher information could benefit from certain 
aspects of the method and apparatus of the present 

10 invention. 

[0O25] Generally, however, the techniques of the 
present invention are best used by broadcast video and 
data systems havir^ a leirge number of available pro- 
grams, data and sen/ices. thereby benefitting from the 
IS sinrplification of programming organization and selec- 
tion provided by the present invention. A prefered 
broadcasting system is the satellite-based system uti- 
lized by the DIRECTV® broadcast service Such 

30 receiving antenna to acquire real-time video broadcasts 
and periodic data broadcasts used to construct a pro- 
gram guide display. It should be understood, however, 
that many other delivery systems are readily applicable 
to alternate embodiments of the present invention. Such 

25 systems include wired or cable dstribution systems, 
UHFA^HF radio frequency systems or other terresb'ial 
broadcast systems (e.g., MMDS. LMDS, etc.), and fiber 
optic networks. 

[0026] FIG. 1 iBustrates a typical Direct-to-Home 

30 (DTH) PC-based satellite communication system 100 
capable of utilizing the present invention. The system 
100 includes a transmission station 102. a satellite^relay 
104, and a plurality of rec&ver stations, one of which is 
shown at reference numeral 106. Wireless communica- 

3S tions are provided between the transmission station 
102. the satellite/relay 104. and the receiver station 106. 
The transmission station 102 includes programming 
sources 108. a oontiol data source 1 10. a data senm:e 
source 112. one or more program guide data sources 

40 1 14, a video/audio/data encoding system 11 6. an uplink 
frequency converter 118, and an uplink antenna 120. 
The data servk;e source 1 1 2 receives data service infor- 
mation and webpages made up of text files, graphics, 
audio, video, software, etc. from a network 122 (e.g., tfie 

45 Internet a LAN or a WAN). The satellite/relay 104 is 
preferably at least one geosynchronous or geostation- 
ary satellite. The receiver station 106 shown in FIG. 1 
includes a reception antenna 124 connected to a tow- 
noise-t>lock (LNB) 126, and an integrated 

50 receiver/decoder (IRD) embodied in a personal compu- 
ter (PC) 128 having a monitor 130 and a computing unit 
132. Other devices, such as another video display 
device (e g., television) 134 and a video recorder 136 
(e.g. VHS. DVH& DVD, etc.), may also be supported, if 

55 desired. 

[0027] In operation, the programming sources 108 
receive video and audio programming from a number of 
sources, including satellites, ten^estrial fber optics. 
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cat^e. or tape. The received programming signals, 
along with data signals from the control data source 
110, the (teta s&vice source 112. and the program 
guide data sources 114. are sent, to the 
vuleo/^udio/data encoding system 116 where they are 
digitally encoded into information data streams that are 
nuittiplexed into a packetized data stream or bitstream 
using a number of conventional algorithnrs. Each data 
packet within the packetized data stream includes a 
header that klentifies the contents of the data packet 
and a service Oyann^ identifier (SCID) that identifies 
the data pack^. In a conventional manner, the encoded 
bitstream is modulated and sent through the upfink fre- 
quency convener 118. which converts the modulated 
encoded bitstream to a frecpjency band suitable for 
reception by the satellite/relay 104. The modulated, 
encoded bitstream is then routed from the uplink fre- 
quency convener 118 to the uplink antenna 120 where 
it is broadcast toward the satellite/relay 104. The satel- 
lite/relay 104 receives the rrvxiulated. encoded bit- 
stream and re^oadcasts it downward toward an area 
on earth that includes the recever station 106. The 
reception antenna 124 of the receiver station 106 
receives the signal, which is typically shifted from, for 
example, the Ku-band signal down ta for example, an L- 
band signal by the LNB 126. The LNB output is then 
provided to the PC 128. the television 134 and/or the 
video recorder 136. As noted above, the PC 128 
includes conventional IRD functions (provided, for 
exarnple. by plug-in circuit cards (boards). Thus, when 
the user commands the PC 128 to tune to a particular 
program, the PC 128 associates the user's program 
selection with a transponder and SCID number and 
tunes the IRD to receive data packets from the appropri- 
ate transponder and to select data packets having the 
appropriate SCID number from the multi-program data 
stream. 

[0028] Although not necessary lor proper operation 
of the disclosed system, the receiver station 106 may 
optionally incorporate a connection (e.g., Ethernet cir- 
cuit or modem) to the network 122 for transmitting 
requests and other data t>ack to the transmission statbn 
102 or other location (or a device nDanaging the trans- 
mission station 102 and overall flow of data in the sys- 
tem 100) and for communicating with network devices 
138 (e.g., websites) that may be on the network 122. 
[0029] In general, the software executed by the PC 
128 includes many conventional PC operations used to 
generate a graphical user interface (GUI) having a 
mouse-controlled cursor or the ISw. windows, d'atogue 
boxes, buttons, pulldown menus, and other such fea- 
tures that facSitate user selection of various options. 
The GUI of the present inv&rtion is assembled using 
two basic types of external data: ( 1 ) real-time broadcast 
data (e.g. streaming data), and (2) file data (i e.. data 
that is periodically downloaded and ^ored). Real-time 
data includes conventional program guide data (e.g.. 
program attribute data, tuning data, etc.), ticker data 



(e.g.. stocks, sports scores, etc.). some SDP+ records, 
and announcements (eg., updates to the webcast data 
catalog, etc.)- F'lle data includes information tf^ is 
updated periodically such as stitl pictures, moving video 

5 dqps, webpages. data catalog (webcast schedule), linte 
to other internal or external sources of information, and 
various discrete software downk)ads. The GUI of the 
present invention organizes and sin^Iifies the presenta- 
tion of real-time broadcast data and file data by provid- 

10 ing. imer alia, a plurality of pages, wherein each page 
h^ a display with several (fistinct segments. For exam- 
ple, a given page type n^y simultaneously provide stilt 
pictures, moving videos, text, graphics, audk>. and data 
within separate segments. 

IS [0030] The GUI of the present inventron requires 
the presence of appropriate data at the receiver station 
106. One method of generating appropriate data and 
reliably transferring it to the receiver station 106 using a 
hardware configuration as shown in FIG. 1 . is disclosed 

20 in detail below in section G (Data Processing) of this 
(fisdosura Generally, the method set forth in section G 
includes a data transfer technK|ue. referred to herein as 
broadcast file download protocol (BFDP). that operates 
in a one-way broadcast communication link. BFDP is 

25 the subject of a copending commonly assigned applica* 

tion entitled . filed on 

^and bearing serial no. 



. BFDP breaks large data fOes for 

transmission into numerous snail data packets, which 
30 are labeled in a sequential manner at the transmission 
statics 102 and broadcast to the receiver station 106. 
BFDP facilitates the assembly of the labeled data pack- 
ets back into tiie large data file and ^tables identifica- 
tion of missing or cornjpt data packets at the receiver 
35 station 1 06. Any missing or corrupt data packets at the 
receiver station 106 can be obtained and inserted into 
ttieir correct locations in the large data f Oe during sut}se- 
quent transmissions of the large data f Oe. Thus, if during 
the transmission of a large data file a number of its data 
40 packets are missing or corrupt, only the missing or cor- 
rupt data packets need be reacquired during a sut)se- 
quent re-broadcast of the targe data file, and not the 
entire large data file. 

[0031] A method for resolving an Intemet protocol 
45 (IP) address into a physical address is also descrik>ed 
in section G of this disclosure. This method is 
referred to herein as a broadcast address resolu- 
tion protocol (BARP). 6ARP is the sut)ject of a co- 
pending commonly assigned application entitied 
50 , filed on ^and 



bearing serial no. 



BARP is nec- 



essary because all file data (for example a large file 
transferred using BFDP, as discussed above) trans- 
ferred to the receiver station 106 are identified by IP 
55 addresses and, as previously noted, the receiver station 
106 requires a transponder and SCID to tune to receive 
ttie broadcast fOe data. Acc(»rdingly. BARP allows the 
receiver station 106 to rapidly resolve an IP address for 
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a desired program or service into a transporxJer artd 
SCID. 

[0032] To inform the user of when and on what IP 
address the large file mentioned above will be broad- 
cast, session desaiptron protocol plus (SOP +) records s 
are periodically broadcast by the transmission station 
102. SDP + records are the subject of a co-pend- 
ing commonly assigned application entitled 

. filed on ^and 

bearing serial no. / . SDP+ records io 

are processed by the receiver station 106 to produce a 
schedule of all data sen^ice information that will be 
broadcast by the transmission station 102. Additionally, 
the SDP + records are used by the PC 1 28 to build GUI 
pages using selected information resident within the PC is 
system (e.g.. a basic page template 180 as shown in 
FIG. 3) and selected dynamic data that is received from 
the sateQite or an Internet connection. When the user 
I cinches tha rilsrface into another staie or page, ths 
GUI builds the destination page as instructed by the 20 
SDP + records and displays it on the user's PC system 
monitor 130. More detaUs at)0ut the SDP -f records are 
provided in Section I of this disclosure in connection 
with the descriptions of FIGS. 32A-320. 

B. Graphical User IntPffarp (f^t J|) 

1. The Main Menu 

[0033] Now turning to FIG. 2A. an example of a 30 
main menu page 140 for a preferred embodiment of the 
GUI of the present invention is illustrated. The main 
menu page 140 includes a central video window 142, a 
video title 144. a page title 146. a date/time display 148. 
a video channel tuning barlSO. a Video Channels serv- 35 
ice link 152, a Best-of*Web (BOW) data service link 
154, a Software Downloads service link 156. a Data 
Channels service link 158. a schedule function link 160, 
a messages function link 162. a settings hjnctton link 
164, and a pop-up remote control link 166. In the 40 
embodiment shown these are all implemented with a 
standard PC system Windows'** application window 
168. as shown. 

[0034] The main menu page 1 40 provides grapNcal 
"buttons" that nrwy be selected to launch, or provide 45 
links to. four services. The Video Channels service link 
152 launches the GUI into a video and text-based elec- 
tronic program guide. The BestK)f-Web data service link 
154 launches the GUI into a service for pre-selectrng, 
prft^iewing, and viewing various Internet websites that so 
may be broadcast to the receiver station 106 via the sat- 
ellite/relay 104. The Software Downloads service link 
156 launches the GUI into a service for selecting and 
scheduling software for downloading to the user's PC 
128 of the receiver station 106. The Data Channels ss 
sen^ice link 158 launches the GUI into a service for 
selecting and scheduling various types of streaming 
data for downloading to the PC 128 of the receiver sta- 



tfon 106. 

[00351 The main menu page 140 also provides 
graphical tHittons** that may be selected to launch, or 
provide links to. three 'Yunctions": (1) the schedule func- 
tion Onk 160. (2) the rhessages function link 162 and (3) 
the settings funcb'on link 164. All functions are repre- 
sented by graphical buttons that, when selected by the 
user, launch the GUI info the schedule, messages, and 
settings functions, respectively The schedule function 
provides a graphical multi-row saolling grid-based 
guide that shows video/audio programming that is 
scheduled for viewing and software files that are sched- 
uled for downloading. The messages function provkfes 
textual promoUonal and static information related to the 
video. BOW, Data Channels, and Software Downloads 
servfoes. For exanrple. a message may be provkied to 
the user that a requested software download was sue* 
cessfuUy completed, or that a new software title wai be 
a.aliatle at a pardcu!^ iiuta. Tiis set:iij»9s funcJon 
aOows the user to program or configure the various 
operatfonat modes of the receiver station 106 with 
respect to the video. BOW. Data Channels, and Soft- 
ware Downloads services. The layout and content for 
each type of funcUon page display of the present GUI 
depends on what sen^ice has been selected on the 
function page. Thus, the function pages of the present 
GUI change with the current sendee page context. For 
example, the layout and content of a settings function 
page changes as the user changes the function page 
type from VkJeo Channels to Software Downloads. A 
more detailed description of each of the function pages 
and associated links are discussed below in section 3.e. 
in connection with FIGS. 13 -16. 

2. The Page Template fnr Pa ^es Underiving the Maip 
Menu 

I0036J Turning now to a more detailed desaiption 
of the GUI. illustrated in FIG. 3 is the basic page tem- 
plate 180 that may be stored within a local memory of 
the PC 128. and which may be used to buiM many of. 
but not necessarily all. the various GUI pages underly- 
ing the main menu page 140 of the present invention. 
The l>asfo page template 180 includes a main content 
frame 182, the page title 146. the dateAtime display 148. 
and a control panel 184. all arranged as shown. The 
main oortent frame 182 displays information of primary 
interest as the user navigates through the various 
pages of the GUI. The main content frame 182 may 
contain live video/audio programming, webpages. linte 
to webpages or sen/ices, links to ticker data, program 
guide information, or links to any other information 
taken from streaming or ffle data that the user is inter- 
ested in and which is consfetent with the cun-ent page 
selected by the user. The page title 146 contains the 
name of the current GUI page or state. The date/time 
display 148 continuously cfisplays current date and time 
information that is received from the broadcast data 
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Stream and is corrected by the GUI software to reflect 
the local date and time for the PCs location. 
(0037] The control panel 1 84 nray further include a 
special links segment 186, a sub-page links segm&tt 
188. a functions toggle 190. the pop-tp remote control 
link 166. and a n^in menu fink ^92, The special finks 
segment 186 may contain a plurality of graphics repre- 
senting progranre and services of special inteest to the 
user (e.g. websites, software titles available for down- 
load, etc.). Using conv&itionai mouse-controlled point 
and click operations or the like, the user may select one 
or more ol the special links graphics to launch the GUI 
directly into the selected service, program, etc. The sub- 
page links segment 188 typically contains graphic but- 
tons f epiesenting other GUI pages that are linked to the 
current GUI page. The user may launch the GUI into 
one of the tinked pages by selecting one of the graphic 
buttons in the subi>age links segment 188. The func- 
tions toggle 190. when selected by the user. launches 
the GUI into a modtfied display state having tabbed 
function pages within the main content frame 182 (e.g., 
as shown in FIG. 12) that are layered underneath the 
service page from which the functions toggle 190 was 
selected. The pop-up renwte control link 166 contains a 
graphic represeming a pop-up remote control. The user 
may select this graphic to overlay a context sensitive 
(i.e.. page dependent) simulated remote control 
(shown, e.g.. in FIGS. 20 and 21) ov^ a portion of the 
display. The format and operation of this context sensi- 
tive simulated remote control is discussed in section 
4.b. (Pop-Up Rennole Control) of this disclosure. The 
main menu link 192 contains a graphic representing a 
link to the nrwin menu page (shown in FIG. 2A). The 
user may select this graphic to launch the GUI from a 
current page displaying the graphic back into the main 
menu page 140. 

3. Pages and Links Underlvino the Main Menu 
a. Pest gf the Web 

[0038] As previously mentioned, webpage and/or 
website information may be downloaded to the PC 128 
and stored within the computing unit 132 for display on 
the nwnitor 130. This information is best accessed and 
presented using the GUI of the present inventioa For 
example, the BOW data service described below alk>ws 
the user to select various websites for downloading and 
storage on his or her receiver station 106. 
[0039] As previously set forth, webpage information 
may be downloaded and stored in the receiver station 
106. Accordingly, the GUI of the present invention is 
adapted to handle webpage information through a sen/- 
ice referred to as Best-of-Web (BOW). Illustrated in FIG. 
4 is a state diagram depicting a BOW data service 200. 
The BOW data sen^ice 200 includes the mam menu 
page 140, the Best-of-Web data service fink 154, the 
main menu fink 192, and a BOW introduction page 202 



that indudes basic informatbn im the iser on how to 
use the BOW data service 200. Adcfitk>naDy. the BOW 
Introduction page 202 indudes a status bar (not shown) 
that indicates the progress of a program guide down- 

5 load to the user's PC 1 28. and a finked group of BOW 
si^^pages 204. The finked group of BOW sub-pages 
204 includes a My Selections sut>-page 206 that allows 
a user to review and deselect web^tes for downloading 
from a personal library of websites, an Add Selections 

10 sub-page 208 that allows a user to preview and select or 
deselect avaitable w^tes tor regular download to the 
personal library of websites, a Special Events sub-page 
210 that includes a group of topical or special interest 
mandatory websites fi e., websites that are downloaded 

IS to the PC 1 28 whether or not th^ are requested by the 
user) that may be selected for viewing by the user, and 
a View Site sub-page 212 that allows a user to display 
selected websites. 

[0040] The pages and sub-pages of the BOW data 

20 servrce 200 are linked together as shown in FIG. 4. The 
arrows represent directional links that when selected 
by a user on a given page, launch the GUI alor^ the 
direction of the arrow into another state or page. In the 
prefened entxxfiment the links are represented by 

25 graphkal tiuttons or togos that, when selected by the 
user, invoke the associated fink and launch the GUI into 
the corresponding page display/state. The BOW data 
servkie 200 s invoked by selecting the Besl-of-Web 
data service fink 154 from the main menu page 140. 

30 The first time the user bunches the GUI along the Best- 
of-Web data senrice fink 154. the GUI displays the BOW 
introduction page 202. From the BOW introduction page 
202, the user may ^er the Add Selections sub-page 
208 by invoking a fink 214. or nrtay return to the main 

35 menu page 140 from the BOW introductksn page 202 by 
invoking the main menu fink 192. After the fir^ use of 
the BOW data service 200. selection of the Best-of-Web 
data service fink 154 (firectly launches the GUI Into the 
My Selections sub-page 206. From the My Selections 

40 SLA)-page 206, the user may launch the GUI into the 
Add Selections subiDage 208 by invoking an Add Selec- 
tions fink 214, into the Speciat Events sub-page 210 by 
invoking a Special Events fink 216. or into the View Site 
sub-page 212 by invoking a View Site Iink218. From the 

45 Add Selections subi>age 208 the user may launch the 
GUI into the My Selections sUb-page 206 by invoking a 
My Selections link 220 or the Special Events sii>-page 
210 by invoking the Special Events link 216. From the 
Special Events subi)age 210 the user nr^ay launch the 

so GUI into the My Selections sub-page 206 by invoking 
the My Selections link 220. into the Add Selections sub- 
page 208 by invoking the Add Selections fink 214. and 
into the View Site sub-page 212 by invoking the View 
Site link 218. From any page within the group of BOW 

55 sut>-pages 204 the user may launch the GUI back to the 
main menu page 140 using the main menu link 192. 
[0041] The sub-pages of the BOW data senhce 200 
are constructed in accordance with the basic page tem- 
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plate 180 (shown in Fia 3). Illustrated in FIGS. 5 and 7 
are exarrpies of the Add Selections sub-page 208 and 
the My Selections sub-page 206 displays, respectively. 
As shown in these figures, the special links segment 
186 contains a plura&ty of graphics or logos that repre- 
sent topical. Of othenMse noteworthy website that are 
niandatory download websites. Mandatory download 
websites are regularly/joeriodically downloaded and 
stored in the local memory of the users PC 128 regard- 
less of whether the user requests a download of any 
mandatory sites. When the iser selects one of these 
graphics the GUI launches directly, via the View Site link 
218. into the View Site sub-page 212 and displays the 
contents of the selected site to the user. The control 
panel 184 further includes the sub-page links segment 
188. The sub-page links segment 188 contains a plural- 
ity of page links represented by graphic txitlons. The 
graphic buttons have labels that indicate the page the 
GUI will be launched into when they are selected by the 
user. The sub-page links segment 188 includes graphic 
buttons representing the My Selections enk 220. the 
Add Selections link 214. and the Special Events link 
216. At the base of the control panel 184 are the pc^up 
remote control link 166 and the main menu link 192. 
[0042] The content off the main content frame 182 
varies with the particular sub-page in which the GUI cur- 
rently resides. For example when the GUI is in the Add 
Selections subi»ge 208 (as shown in FIG. 5) the main 
content frame 1 82 contains a matrix of graphic sut>-seg- 
ments representing a library of available websites. The 
website sub^egments are preferably an'anged alpha- 
betically within predetermined categories. Categories 
may be general areas of user interest such as Entertain- 
ment. Rnance. Lifestyle. News, and Sports. Each of the 
website sub-segments 222. further includes a website 
logo 224 representing the website, a website title 
header 226. a website size indicator 228. a preview but- 
ton 230. and a select button 232 or a deselect button 
236. The user can preview a website by selecting either 
the website logo 224 or the preview button 230. which 
invokes the View Site link 218 and launches the GUI 
into the View Site sub-page 212. Selecting a website 
preview invokes a "pop-up" preview child window 234 
(shovwi in FIG. 6) that contains a general description of 
the oorrtents of the particular website and a selection of 
media graphics. 

[0043] Website sub-segments 222 that have been 
selected for download to the PC 128 have a Nghlighted 
{G.g., red) deselect button 236. Website segments that 
have not been selected for download have an alter- 
nately highlighted (e.g.. gray) select button 232. By 
selecting the select button 232 or the deselect button 
236 the user toggles the website between select and 
deselect conditions. The website selection/deselection 
process may invoke the appearance of several child 
windows (not shown, but similar to the child window 234 
shown in FtG. 6). For example, when the user "dteks 
on" the select or deselect buttons, the system produces 
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a pop-up chiW window that prompts the user to conf rm 
the selection or deselection of the website. The user 
may additionally have the options of oonf trming/accept- 
ing the requested selectton/deselection, canceling the 
5 selection/deselection and returning to the page dsplay 
that initiated the child window, and disabling future 
appearances of the interposing child window. 
[0044] Aftematvely. if the GUI is in the My Selec- 
tions subi)age 206, as shown, for example, in FIG. 7, 
10 then the main content frame 182 includes a matrix of 
graphic sub-segments representing a IS)rary of user 
selected whites that are arranged, organized, and 
represented in a similar manner to those In the Add 
Selections sub-page 208 described above. The user 
1$ may similarly view a website by either selecting the 
website logo 224. or a view button 238, which invokes 
the View Site link 218 and launches the GUI into the 
View Site sub-page 212. In the View Site sut>i3age 212, 
riarn content frrrr 1S2 d!tp!3>s ths selsctrrf ivsb- 
20 site's pages. From the My Selections sub-page 206. the 
user may also deselect a site so that it is removed from 
the group of sites that are downloaded to the k>cal mem- 
ory of the PC 128. A pop-up chiW window confirming the 
requested deselectton is preferably presented to the 
25 user. The logos for sites that are scheduled for removal 
from the satellite transmissk)n system are cfisplayed 
with a news button (not shown) rather than a view but- 
ton. When the user selects the news button, an inter- 
posing pop-up child window wams of the pending 
30 disoontinuation of the website from the satellite system 
and allows the user to launch into the View Site sub- 
page 212. 

[0045J If the GUI is in the Special Events sub-page 
210 (not shown, but similar to the Add Selections sub- 
ss page 208). then the main content frame 182 displays 
rows of graphic sut>s^ments representing a group of 
topical or special interest mandatory download wet>sites 
(not shown). As with the Add Selections sub-page 208 
and My Selections sub-page 206 the website sub-seg- 
40 ments are preferably arranged alphabdically within pre- 
determined categories. Categories may be Hot Topics. 
Sites of the Month, or other similar topical headings. 
Each website sub-segment includes a logo represent- 
ing the website, a website title header, a view button. 
4S and a preview description. The preview description pro- 
vides a brief textual overview of the contents of the site. 
The user can view a site by selecting either the logo or 
the view button, which invokes the View Site link 218 
and launches the GUI into the View Site sub-page 212. 
so [0046] The GUI of the present invention allows for 
the rapid determination and display of the availability of 
selected information. A web cache status (i.e.. whether 
or not a webpage is stored on the PC 128) is conveyed 
automatically to the user from various pages of the GUI. 
55 Wrthin the Add Selections sub-page 208. the My Selec- 
tions sub-page 206. and the Special events sub-page 
210 a cursor rollover of any webpage logo/sub-link will 
indicate to the user whether that particular wet)page is 
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(ocafly cached or not To perfomi ths function rapidly 
emuigh to present the static to the user in real time, the 
system maintains a hash tat)le of ail the w^spages that 
are cached in local memory (e.g., RAM or hard di^). A 
h^ tat)le of aO the enrtedded links is aeated for each 
(fisplayed frame of the GUI pages tfmt include website 
logos. The system then makes a single request from the 
system's proxy server to retrieve the cached state of 
each link. The cached status for each emtsedded link is 
then stored in the hash taUe. Thus, as the user moves 
the cursor over a wetTsite togo/link. the system can rap- 
kly determine cached status and display this static to 
the i^er via an appropriate graphic (eg. a f tngerAio fin- 
ger graphic may be used as a universal yes/rto indica- 
tkm). 

b. Software Downloads 

[0047] One type of file data that may be down- 
loaded to the receiver station 106 and stored in the 
computing unit 132 is commercially-available software 
(ag.. Quk*en™). 

[0048] Illustrated in FtG. 8 is a state diagram depict- 
ing a Software Downloads data service 240. The Soft- 
ware Downtoads data service 240 includes the main 
menu page 140, the Software Downloads service link 
156. the main menu link 192. a Software Downloads' 
introduction page 242. and a linked group of Software 
Downloads sub-pages 244. The Software Downloads 
introduction page 242 includes basic text information for 
the user on how to use the Software Downloads data 
s^ce240. 

(00491 The Software Downloads sub-pages 244 
further include a Full List sub-page 246 that displays all 
software available for downloading, a Specials sub* 
page 248 that displays promotional software available 
fa downloading, a Hot Ust sub-page 250 that displays 
popular software available for dCMmloading. and a soft- 
ware preview sub-page 252 that contains a general text 
desaiptk>n of the user selected software. The pages of 
the Software Downloads data service 240 are linked 
together as shown in FIG. 8. The Software Downloads 
data service 240 Is invoked by selecting the Software 
Downk)ads service link 156 from the main menu page 
140. Once invoked, the Software Downk)ads data sen/- 
ice 240 (£splays the Software Downloads introduction 
page 242. From the Software Downloads introduction 
page 242 the user may either r^um to the main menu 
page 140 via the main menu link 192. or may launch the 
GUI into the Full Bst sub-page 246 by invoking a Full list 
link 254. From the Full list sub-page 246, the user may 
launch the GUI Into the Hot List sub-page 250 by invok- 
ing a Hot list link 256. into the software preview sub- 
page 252 by invoking a preview link 258. or into the Spe- 
dats sub-page 248 by invoking a Specials link 260. 
From the Hot Ust sut>-page 250. the user may launch 
the GUI into the Full Ust sub-page 246 by invoking the 
Full List link 254. into the software preview sut>-page 



252 by invoking the preview link 258. or into the Spe- 
dais sut>i)age 248 by invoking the Specials link 260. 
Rom the Specials sub^Mge 248 the user may launch 
the GUI into the FuO List sub^ge 246 by invoking the 

5 FuD fist fiiTk 254, into the software preview sub^ge 252 
t>y invoking the preview link 258. and into the Hot List 
sub-page 250 by invoking the Hot 6st link 256. From the 
software preview subi3age 252 the user way launch the 
GUI into the Hot List subiiage 250 by invoking the Hot 

10 List link 256. into the Full List subi)age 246 by invoking 
the Full L^ link 254. or into the Spedals sub^;>age 248 
by invoking the Specials link 260. The user may launch 
the GUI back to the main menu from any of the pages of 
the Software Downk>ads data service 240 using the 

IS main menu link 192. 

[0050] The pages of the Scrftware Downk)ads data 
service 240 are constructed in accordance with the 
basic page template 1 80 (shown in FIG. 3). Illustrated in 
FIG. 9 is an example of the FuU list sii>-page 246. As 

20 shown in FIG. 9. the special links segment 186 contains 
a plurality of graphics or logos representing the five 
most popular software titles that are available for down- 
k>acfing. When a user selects one of these logos/graph- 
ics the GUI is launched into the software preview sub- 

25 page 252 from which the us& is given a general textal 
description of the sheeted software. The control panel - 
184 further includes the sub-page links segment 188. 
The sub-page links segment 188 indudes a pluraGty of 
page links represented by graphk: buttons having labels 

30 that correspond to the page the GUI wiO be launched 
into when they are selected by the user. The sub-page 
links segment 188 indudes graphic buttons that repre- 
sent the Full List link 254. the Hot Ust link 256. and the 
Spedals Unk260. Thus, by selecting the graphic button 

35 labeled ''Hot UsT the GUI will be launched via the Hot 
Ust link 256 into the Hot Ust sub-page 250. At the base 
of the control panel 184 are the pop-up remote control 
link 166 and the vnain menu link 192. 
[0051 ] As previoudy noted, the coment of the main 

40 content frame 1 82 varies with the particular subi)age in 
which the GUI currently resides. Wh^ the GUI is in the 
Full List sub-page 246 (as shown in FIG. 9). the main 
content frame 1 82 contains a matrix of graphfc suthseg- 
ments representing a library of software titles that are 

45 available for download. Each software sub-segment fur- 
ther indudes a software logo 262 representing the par- 
ticular software title, a software title header 264. a 
software preview button 266. a download button 268. 
and a textual software description 270. The user can 

so preview a software title by selecting either the software 
logo 262 or the software preview button 266. Selecting 
either the software logo 262 or the software preview but- 
ton 266 invokes the preview link 258. which launches 
the GUI into the software preview sub-page 252. In the 

55 software preview sub-page 252 the user is given a more 
detailed textual desaiption of the selected software title. 
The user may downk)ad a software title by selecting the 
title using the downk>ad button 268 on the Full Ust sub- 
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page 246 or from the software preview sub-page 252. 
[0052] If the user selects the download button 268 
for a particular software title, he/she is presented with a 
set of choices for available download date/b'mes for that 
title. The GUI may display for the user a corrfirmation s 
that they are about to schedule the download of a soft- 
ware title and may additionally provide other information 
pertinent to the download such as software version 
options. If the user selects one of the available down- 
load date/bmes then a download is scheduled for that / 
date/bme. At the scheduled date/lime for a download, 
the receiver staton 106 automatically tunes to the 
proper iransponderAeed and uses BFDP to capture and 
record that download. A message is sent with suc- 
cess/lail information for the download and is resched- u 
uled if necessary. 

[0053] The Hot List sub-page 250 is similar to the 
Full Ust sub-page 246 except the software titles shown 
are selected based on their popularity The Sped?»!s 
subijage 248 is also similar to the Full Ust sut>-page 2C 
246 except the avail^e software titles are selected for 
promotional purposes. Both the Hot List sub-page 250 
and the Specials sub-page 248 allow the user to down- 
load softvrare either directly via the download button 
268, or through the software preview sut>-page 252. 25 

c. Data Channels 

[0054] Illustrated in FIG. 10 is a state diagram 
depicting a Data Channels data service 280. The Data 30 
Channels data service 280 includes the main menu 
page 140, the Data Channels service link 158. the main 
menu link 192. a Data Channels introduction page 282 
that includes basic textual information for the user on 
how to use the Data Channels data service 280, and a 3s 
linked group of Data Channels sub-pages 284. The 
linked group of Data Channels sub-pages 284 further 
includes a Selection sub-page 286 that presents to the 
user the data sen^ices available, a Data Channels pre- 
view sub-page 288 that allows a user to preview a 40 
selected data service, a Schedule sub-page 290 that 
contains download information such as price, available 
software options and downtoad schedule details, and a 
Confirmation sub-page 292 that acknowledges a newly 
downloaded data service for the user. 45 
[00551 The pages and sutepages of the Data Chan- 
nels data service 280 are linked together as shown in 
FIG. 1 0. The Data Channels data sen^ice 280 is invoked 
by selecting the Data Channels service link 158 from 
the main menu page 1 40. By selecting the Data Chan- so 
nels sen^ice link 158, the GUI launches into the Data 
Channels introduction page 282. From the Data Chan- 
nels introduction page 282 the user may go back to the 
main menu page 140 by selecting the main menu link 
192 or may launch into the Selection sub-page 286 by 55 
invoking a Selection page link 294. From the Selection 
suthpage 286 the user may launch into the Schedule 
sub-page 290 by invoking a Schedirie page link 298 or 



may launch Into the Data Channels preview sub^ge 
288 by invoking a preview page Dnk 296. From the Data 
Channels preview sub-page 288 the user may launch 
into the Selection sub-page 286 by invoking the Selec- 
tion page link 294 or may launch into the Schedule sub- 
page 290 by invoking the Schedule page link 298. From 
the Schedule sub-page 290 the user may launch into 
the Data Channels preview subiMge 288 t>y invoking 
the preview page link 296 or may launch into the Conf ir- 
) mation sub-page 292 by invoking a Confirm page link 
300. From the Confirmation sub-page 292 the user may 
return to the Selection sub-page 286 by invoking the 
Selection page link 294. Additionally, the user may 
return to the main menu from any of the sub-pages by 
\ selecting the main menu link 1 92. 
[0056] The sub-pages of the Data Channels sen/ice 
220 are constnicted in accordance virrth the basic page 
template 180 (shown in FIG. 3). Illustrated in FIG. 1 1 is 
an of ths Ss'erfoi s^'b-p^,2^ 2?S. Th3 co*^ol 

panel 184 of the Selection sub-page 286 contains only 
the functions toggle 190, the pop-up remote control link 
166. and the main menu link 192. The ntain content 
frame 182 of the Selection sub-page varies with the par- 
ticular sub-page in which the GUI currently resides. For 
example, when the GUI is in the Selection sub-page 
286 (as shown in FIG. 11), the main content frame 182 
contains a plurality of sub-segments representing the 
various data channel servk;es that are available. Each 
data channel sut>-segment contains a data channel logo 
302, a data channel preview button 304, a data channel 
launch button 306. and a data channel desajption 308. 

d. Video Channels 

[0057] Selection of the Video Channels senrice lif* 
152 (FIG. 2A) launches the GUI into a multi-segment 
electronic program guide 310 shown in FIG. 12. The 
electronic program guide 310 includes a grid-based 
channel guide 3 1 2. the channel tuning bar 1 50 (also dis- 
played in the main menu page 140). the pop-up remote 
control link 166. the main menu link 192, an active vWeo 
window 314, a program description 316, and an elec- 
tronic program gukJe configuration header 318. 
[0058] The grW-based channel guide 312. uses a 
Gantt chart style layout with time of day along one axis 
and channels along the other. The user can tune to a 
desired channel by selecting a partwular row/column of 
the grid-based channel guide 312, using the channel 
tuning bar 150 or the pop-up remote control link 166. 
Both the channel tuning bar 1 50 and the pop-up remote 
control link 166 are desaibed in more detail later in this 
disclosure under sections 4.a. (Tuning Bar) and 4.b. 
(Pop-Up Remote Control), respectively 
I0059J The active video window 314 displays pro- 
gramming from the cunently selected channel. The pro- 
gram description 316 may include a variety of program 
information such as an abstract of the program, the time 
slot, the rating, and the availability of closed captioning 
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fa a currently higjtltghted grid guide program. The ^ec- 
tronic program guide configuration header 318 allows 
the iser to fitter the cont&ns of the program grid based 
on the day. the kind of program, the time slot, or accord- 
ing to predefined categoric 5 
[0060] As described earlier, the GUI of the present 
invention provides several function pages that work to 
improve the GUfs flexibflity, and assist the user in f flter- 
ing and managing the large amount of Iriformation avail- 
atjie. These function pages niay be launched from the io 
main menu page 140 (shown in FIG. 2A) via the func- 
tion links 160. 162. 164. from a service page by select- 
ing the functions toggle 190. or from the grid-based 
channel giide by selecting the tabs at the bottom of the 
guide. 

e. FuiKtiOP P^qe^ 

(0061 J Illustrated in FIG. 13 is a state diagram 
depicting the organization of the function pages that are 20 
associated with the main menu page 140. From the 
main menu page 140. the user may invoke the schedule 
function link 160 to launch the GUI Into an interlinked 
group of schedule sub-pages 320, the messages func- 
tion link 162 to launch the GUI into an int^inked group 2S 
of messages subi)ages 330. or the settings functfon 
link 164 to launch the GUI into an Interlinked group of 
settings sub^jages 340. The schedule sub-pages 320. 
messages sub-pages 330, and the settings sub-pages 
340 are further interlinked via the schedule function link so 
160. the messages function Gnk 162. and the settings 
function link 164 as shown in FIG. 13. The main menu 
link 192 may be invoked from any subi^ge to go back 
to the main menu page 140. 

[0062] The various function pages illustrated in FIG 35 
13 may also be accessed from the various service 
pages by selecting the functions toggle 190. In the pre- 
ferred embodiment, if the user has selected a function 
page from within a data sen/tee (using the functions tog- 
gle 1 90), in order to link to another data service the use* 40 
must also exit the function pages via the data service 
from which the functions toggle was selected. Thus, the 
user can freely navigate between the various function 
pages assodated with the available data services once 
the function pages have been Rnked to via the main 45 
menu or from within a data service page, but hefehe 
cannot navigate between data services from within the 
function pages. In other embodiments, it may. however, 
be desirable to allow the user to freely navigate between 
the various data services from within any state of the so 
GUI. 

[00631 The schedule sub-pages 320 include a TV 
schedule page 322, a Data Channels schedule page 
324. a Software Downloads schedule page 326. and a 
Best-of-Web schedule page 328. These sub-pages 320 ss 
are alt interlinked as shown. Additionally, the GUI may 
be launched from any schedule sub-page into a corre- 
sponding data senrice. From the TV schedule page 322 
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the GUI may be laundied. va the Vdeo CJhannels serv- 
ice link 1% into the electrortic program guide 310 
(shown in FIG 12). From the Data Q^nnete schedule 
page 324 the GUI may be launched, via the Data (Chan- 
nels sennce link 158, into the Data Channels data serv- 
ice 280 (shown in FIG 10) if that service is oirrenUy 
active/selected, from the Software Downloads schedule 
page 326 the GUI may be launched, via the Software 
Downloads savice link 156. into the Software Down- 
loads data service 240 (shown in FIG 8) if that servk;e 
is cunently active/selected, and the from the Best-of- 
Vyeb schedule page 328 the GUI may be launched, via 
the Best-of-Web data servk;e link 154. into the BOW 
data service 200 (shown in FIG. 4) if that sendee is cur- 
rently active/selected. 

[0064] The schedule sd)-pages 320 provide a user- 
delined multi-day event calendar 350 (shown, e.g.. in 
FIG. 14). From the event calendar 350. the user can 
review upcoming events (e.g. TV shov^rs, software 
downloads, etc.), remove scheduled events, or may 
review past events. The multi-day evOTt calendar 350 
includes scroll anrows 352 that allow the user to adjust a 
central schedule view 354 up/down by days or left/right 
by hours. A filter section 356 aDows the user to selec- 
tively filter what programs appear in the central sched- 
ule view 354. For example, the user may adjust the 
fSters to display only scheduled software downk}ads. A 
current/upcoming events section 358 displays a textual 
list of scheduled events, such as a television show, a 
software downbad, a special/topical tele^ion program, 
etc. When the user highlights one event from the list of 
the events in the cunent/upcoming events section 358 
an events text box 360 displays addtional infomnation to 
the user associated with the highlighted event A review 
button 362, when selected, allows the user to review 
details of a particular scheduled event. Fa example, the 
date and time for a software download can be reviewed, 
modified to an alternative date and time, or may be can- 
celed. A history button 364. when selected, allows the 
user to review past software downloads and televisk>n 
programs. 

[0065] The messages sub-pages 330 include a TV 
messages page 332. a Data Channels messages page 
334, a Software Downloads messages page 336, and a 
BeslHrf-Web messages page 338. The messages sub- 
pages 330 are all Interlinked as shown in FIG. 13. From 
the TV messages page 332 the GUI may be launched, 
via the Vkleo Channels service Gnk 152, into the elec- 
tronic program guide 310 (shown in FIG. 12) if that serv- 
ice is cunemiy active/selected. From the Data Channels 
messages page 334 the GUI may be launched, via the 
Data Channels sen/ice link 158. into the Data Channels 
data sendee 280 (shown in FIG. 10) if that service is 
cuaentiy active^selected. from ttie Software Downloads 
messages page 336 the GUI may be launched, via the 
Software Downloads service link 156. into ttie Software 
Downloads data service 240 (shown in FIG. 8) if that 
service is currentiy active/selected, and the from the 
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Best-of-Web messages page 338 the GUI may be 
launched, via the Best-of-Web data service link 154, 
into the BOW data service 200 (shown in Fia 4) if that 
service is currently active/selected. All the messages 
sub-pages allow a user to view promotional and ^tus 5 
text messages related to the current service page type. 
For example, the Software Downloads messages page 
336 (shown, e.g.. In FIG. 15) includes textual, promo- 
tional and status messages related to available or 
scheduled software downloads. A messages summary to 
366 provides one-line text summaries desaibing the 
various messages that can be selected for viewing by 
the user. A message body 368 is displayed for the cur- 
rently highlighted message. A remove button 370, when 
selected, eliminates the currently highlighted message is 
from the display 

[0066] The settings sub-pages 340 include a TV 
settings page 342. a Data Channels settings page 344. 
r ^r:^^;-.-. DcA'-'r^iG cettirsG p-gs 2*S, s ^*ct- 
of-Web settings page 348. The settings sub^pages 340 20 
are all interlinked as shown in FIG 13. Additionally, from 
the TV settings page 342 the GUI may be launched, via 
the Video Channels sendee link 152, into the electronic 
program guide 310 (shown in FIG. 12) if that data serv- 
ice is currently active/selected. From the Data Channels 25 
settings page 344 the GUI may be launched, via the 
Data Channels service link 158. into the Data Channels 
data service 280 (shown In FIG. 10) if that service Is 
currently activefeelected, from the Software Downloads 
settings page 346 the GUI may be launched, via the 30 
Software Downloads servwe link 156, into the Software 
Downloads <teta service 240 (shown in FIG. 8) if that 
data service is currently active/selected, and the from 
the Best-of-Web settings page 348 the GUI may be 
launched, via the Best-of-Web data service link 154, 35 
into the BOW data service 200 (shown in FIG 4) if that 
data service is currently active/selected. 
[0067] "me TV settings page 342 (shown, e.g., in 
FIG. 16) allows a user to configure audio tracks (i.e. 
choice of language), select or lock-out satellite and 4o 
broadcast channels, configure inputs (e.g. antenna, 
cable. HRC. IRC), set spending limits tor pay-per-view 
selecttons, set ratings limits, nrodify display dimensions, 
configure the antenna (i.e. enter the antenna coordi- 
nates), activate closed captioning, service test the sys- 4S 
tern, and configure an enriched TV mode (i.e.. set the 
maximum cache size for enriched TV in kilobytes). The 
Software Downloads settings page 346 allows the user 
to set the download directory in which download files 
will be stored. The Best-of-Web settings page 348 so 
allows a user to modify Internet settings (e.g.. cache 
size), change webcast settings, and define the proxy 
server and browser specific settings. 



4. Tuning Interface 
a. Tuning Bar 

[0068] An important aspect of the present invention 
is the graphical channel tunir^ bar 150. As shown oi 
FIGS. 2A and 2B. the channel tuning bar 150 has a 
slider 372. an up anrow 374, a down arrow 376. a chan- 
nel number 378. and a channel call-sign 380. The chan- 
nel tuning bar 150 is automatk^afly scaled so that the 
channels a particular user is entitied to see are evenly 
distributed along the vertical length of the channel tun- 
ing bar 150. In operatioa the vertical position of the 
slider 372. the channel nurriwr 378. and the channel 
call-sign 380. all correspwid to the incoming 
video/audio programming that ts currently being 
selected t3y a tuner 426 and a transport functional 
processing block 432 (shown in FIG. 22). and routed to 
snd optzrsJ^y disp^ycd \r, the cantrd \':t^zo v.lnCz^j 
142. The user can change the current video channel 
selection In four ways. First the user may increment or 
decrement the selected video channel by selecting the 
up arrow 374 or the down arrow 376. respectively Sec- 
ond, the user can move the slider 372 directiy to a 
desired vertical position or channel by grabbing the 
slider with the cursa and dragging it along the channel 
tuning bar 150. Third, the user can move the cursor to 
point to a specific vertical position along the channel 
tuning bar 150. and fourth, tiie user may enter numeric, 
at^ha, or alphanumeric information related to a new 
channel directiy via the PC's keyboard. 
[00691 Holding the cursor over any portion of the 
channel tuning bar 150 produces a pop-up window that 
displays to the user the channel number and call-sign of 
the channel associated with that location on the channel 
tuning bar 150. Thus, when tfie user sees a desired 
channel nunr*>er or call-sign in the pop-up window ttiey 
may select that point along the tuning bar so thai the 
slider 372 moves directly to the channel associated with 
that position. Once a new channel has been selected, 
the channel number 378, the channel call-sign 380, the 
vertical position of the slider 372, the video displayed in 
tfie central video window 1 42, and the vdeo titie 1 44 are 
updated to correspond to ttie newly tuned/selected 
channel. 

[0070] In the disclosed embodiment, the channel 
tuning bar 150 is divided into a number of locations, or 
increments, equal to ttie number of available tunable 
channels, services or other available selections. It is 
known that individual users in high capacity DTH sys- 
tems may subscribe to one or more available program- 
ming packages. Access to tfie available services is 
limited using conventional conditional access systems. 
Different users may sulscribe to difterert channels, or a 
given subscriber may change its authorizations over 
time. 

[0071] It is desirable, therefore, to accommodate 
changes in the channel authorizations so that channel 
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tuning barl 50 has an e^ly distrftxited display without 
any 'dead zones' or gaps. The top-most position in the 
vertical channel tuning bar 150 could, tor exanple. cor- 
respond to a first service (ag. the Imest numbered 
ct^nel that the particular user is authorized to 5 
receive), while the lowest position on the channel tuning 
bar 150 oon-espcrtis to the oppo^ extrme (e.g. the 
highest nunrt>ered channel the user is authorized to 
receive). Within this range, channels that the user Is 
authorized to receive are dynamkaily distributed alorrg 
the channel tuning bar 150 such that the spaces 
between each channel's "area" on the tuning bar is sub- 
stantially equal, regardless of the nunnber of channels 
available fa viewing. 

[0072] To achieve this result, processors within the 
PC's computing unit 132 (FIQ. 2) that are respons&le 
for generating the GUI (including the slider 372 ar^ 
channel tuning bar 150) have access to stored infonna- 
tion corresponding to the channel authorizations or a 
user defined subset of them This local authorization 
Information may be utiftzed to etinrtinate from the cus- 
tomer's grid display (FIG. 12) grid lines or rows corre- 
sponding to unavailable channels. Alternatively, some 
unsubscribed channels may be displayed for promo* 
ttonal purposes. In the same manner, the channel 
authorization data may be used to assemtsle a complete 
subset of available services or other functions for use in 
allocating locations along the channel tuning bar 150. 
[O073] In the disclosed mbodiment the channel 
tuning bar 150 is initialized or configured for display in 
one of three ways: (1) when the GUI code is first exe- 
cuted within the PC 128. (2) when the system receves 
a Main Program Guide (MPG) update message, or (3) 
when a user changes program guide display options 
(&g.. t>y changing one or more parameters within the 
electronic program guide configuration header 318 
shown in FIG. 12). The MPG contains the infonmation 
needed to construct the electronic program guide 310 
(shown in FIG. 12). and is stored in the local memory of 
the PC 128. In addition, the PC 128 receives, via the 
transmitted data stream, messages that irtstruct the GUI 
software to update the locally stored MPG using infor- 
mation parsed from the transmitted data stream. 
[0074] An initialization or configuration of the chan- 
nel tuning bar 150 follows a procedure 390 illustrated in 
Fia 17. In a first block 392. the system selects, from a 
copy of the MPG stored in menxvy, a list of the channel 
numbers and logo names that the user is entitled to 
view. In a second block 394, the selected channel num- 
bers (n = number of selected channels) and their asso- 
ciated names are sorted either by numt)er or name and 
are stored into the system's memory as a data structure 
or channel/services table comprising (n) rows and two 
columns. In a third block 398. the total numk>er of pixels 
available to cfisplay the channel tuning bar 150 is 
divided by the number of selected channels (n) to deter- 
mine how many display pixels nrmy be allocated to each 
of the user's available channds. In a fourth block 398, 



the total length of the channel tuning bar 150 may then 
be dMded between the nunrter of available services or 
other functnns. In certain emtxxfiments. the allocations 
to each channel or furK^tion are equal. In oth^ how- 
ever, it may be dearable to allocate a broader inaement 
cv region of the channel tuning bar 150 to celain chan- 
nels, services, a other functions. This would have the 
effect of making these services more prcmnent and 
easia* to tune (e.g. requiring less precision in placement 
of the slider 372). 

[0075] The displayed position of the slider 372 is 
tracked by the display generating software and com- 
pared to the calculated d^lay pixel locations or incre- 
ments for each channel, service, or action. The kx;atk)n 
or increment corresporKling to each channel may then 
be correlated or mapped to tuning information. For 
example, a matrix or lookup tattle may correlate/irnap 
tuning bar display positions to corresponding irYfbrma- 
tion atxMJt that channel, which is required for dsptay or 
tuning purposes. In other embodiments, pointers may 
include a data structure that conelate/imap tuning bar 
increments so that the pointers point to tuning or other 
program guide information that correspond to the partic- 
ular channel assodated with the display position of the 
slider 372. 

[0076] The channel tuning bar 150 is preferably 
implemented as an ActiveX™ control. Because the com- 
puter code used by the PC 128 employs an ofcjed ori- 
ented encapsulation design, the channel tuning bar 1 50 
may be easily incorporated within, and Intact with, a 
wide variety of page displays. In addition, computer 
code implementing the tuning bar functionality is modu- 
lar and may easily interact with any page within the 
present GUI because the various page displays do not 
l^ve to assimilate the exact computer code implemen- 
tation contained within Hxe encapsulated tuning bar 
object. 

[0077] The conputer code that generates the chan- 
nel tuning bar 150 Is responsive to several types of 
inputs that allow a user to change the displayed channel 
or service. One type of input allows a user to move the 
cursor graphic over a partkuilar portion of the channel 
tuning bar 150 and then 'click" on that portion to display 
the channel or service associated with that portion of 
the channel tuning t>ar 150. The system processes a 
"click* event by following a procedure 400 that is illus- 
trated in FIG. 18. In a first block 402 the desired tune 
slot or row in the channel/services table is tound by 
dividing the cursor*8 current pixel location by the total 
nunnber of pixels allocated to each channel or service. 
In a second block 404 the channel nunnber and name 
are retrieved from the calculated row or time slot in the 
chann^ervices table. In a third block 406. the tuning 
bar code requests the system to tune to the retrieved 
chann^ number. In a fourth block 408. the displayed 
position of the slider 372 is updated to correspond to the 
newly selected chann^, and the assodated channel 
number and name are displayed adjacent to the chan- 
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nel tuning bar 150. 

(00781 As described above, holding the cursor over 
any portion of the channel tuning bar 150 produces a 
pop-up window containing the channel number and call- 
sign associated with that location. Thus, a user's selec- 
tbn of a channel can be greatly fadlitated by these "roll- 
over" events. 

[0079] The system processes a "drag' event using 
a procedure 410 that is illustrated in FIG. 19. In a first 
block 412, the tune slot or row In the channel/service 
table is calculated by dividing the cursors current pixel 
location by the number of pixels allocated to each chan- 
nel or service In a second block 414, the system 
retrieves the channel number and the associated name 
from the cateulated row. In a third block 416, the slider 
position is updated and the channel identifiers are dis- 
played adjacent to the corresponding location along the 
channel tuning bar 150. As a user moves the cursor 
■^•cr- ^^^ channe! tuning bar150. a ripid suzzzzsizr, c? 
"rollover" events will be executed to produce an appar- 
ently seamless display of changing channel numbers 
and associated names that uniquely correspond to the 
changing position of the cursor. 
[00801 User's may also change the displayed chan- 
nel or service by moving the cursor over the slider 372. 
hoWing the primary mouse button and dragging the 
slider 372 to a desired location along the channel tuning 
bar 150. A user may "pick up" the slider 372 with the 
systems^ mouse and move it along the channel tuning 
bar 150. As the slider 372 is dragged along the channel 
tuning bar 150. a rapid series of "drag" events are 
invoked within the system that are simflar to the "rollo- 
ver events descrtoed abova Channels and thar asso- 
ciated names are selected from the channel/seryices 
table based on the pixel location of the system's cursor. 
The slider 372 position is updated to correspond to the 
channel location along the tuning bar selected by the 
cursor. However, when the user releases the primary 
mouse button following a "drag" event, a "dick" event is 
invoked to change the displayed channel/service and to 
update the slider position, the displayed channel 
number, and the displayed channel name or call-sign. 
[00811 Alternatively, users may invoke a change in 
the displayed channel/service by entering numeric, 
a^pha. or alphanumeric information via the system's 
keyboard. The system processes a displayed chan- 
nel/service change received through the system's key- 
board by first searching the channeWservices table for a 
matching channel number or name. If a matching chan- 
nel is found, the system initiates the logical equivalent of 
a "dick" event (as described above and illustrated in 
FIG. 18) to complete the user requested change. 
[0082] The channel tuning bar 150 is primarily 
directed to accommodating video and/or audio pro- 
gramming which is available on selectable channels of a 
DTH or similar system. However, it is also posstole to 
allocate portions of the channel tuning bar 150 to other 
services or functions which can be launched from the 



tuning bar 150. f=dr example, positions of the channel 
tuning bar 150 may be correlated to locally cached infor- 
mation. The matrix or ottier correlating data wouW ttien 
point to or othenwise select, for example, a subroutine 
5 for performing a local function, rather than accessing 
program guide/schedule information to initiate tuning. 
Portions of the channel tuning t>ar 150 may be reserved 
for linking ttie user to other functions of the system, 
such as other menu pages, for exanple. BOW, data 
10 services, etc. Links of this type couM be grouped, for 
exan^le, in a data servk:es portion 377 of the tuning t>ar 
150. 

[0083] The channel tuning bar 150 may also be 
coded to intuitively convey selection information to the 
15 user. For example, several colors may be used to visu- 
ally distinguish sections of ttie tuning bar ttiat con-e- 
spond to particular selection categories 373. 375. 377. 
If the lower portion of the bar is used for linking to alter- 
.-.trv-a rr^cnus or ^jnct'c;:3, ^it pc/acn ol \1.b bar n.cy 
so be shaded or colored in a distinct manner. Similarty. a 
user^ favorite channels or other selected groupings of 
channels may be distinctiy colored or shaded to fecili- 
tate their selection from along the lengtti of tfie tuning 
bar. Selected channels along tfie tuning bar may be dis- 
ss tinguished with lines 381 . adjoining indida 379. or some 
other indication in or adjdning the channel tuning bar 
150. By way of example, the last ttiree. five, or other 
number of previously tuned channels may be marked to 
facilitate returning to them. In other entxxfiments, a 
30 "favorites" Ifet. maintained elsewhere in the system, may 
be used to highlight a othenwise emphasize tiiose loca- 
tions con-esponding to the selected favorite channels of 
a particular user. It will be understood by tfiose skilled in 
this art that many alternative presentations and entxxJ- 
35 iments are similarly possible without departing from the 
scope or spirit of the present invention. 
[0084] Although a single channel tuning bar 1 50 is 
shown, it is understood ttiat multiple tuning bars may 
alternatively be utilized. This may be particularty helpful 
40 where a large number of channels are present which 
would ottierwise cause the Increment corresponding to 
each individual channel to be undesirably small and 
require excessive precision in positioning the slider 372. 
Although the channel tuning bar 150 is illustrated in a 
45 vertical position, it shoidd be understood ttiat other posi- 
tions, or combinations of positions, are similarly possi- 
ble. The channel tuning bar 150 may be straight, 
curved, or some combination thereof. 
[0085] To further facilitate tuning in a high capacity 
50 system (i.e. many available channels and services) it 
may be desirable to provide a resolution functfon or 
acceleration function ttiat adjustably varies ttie rate at 
which ttie slider 372 moves along the channel tuning 
bar 150. For exanple, large user movements of ttie 
55 sikier 372 relative to the channel tuning bar ISO may 
cause a rapid movement through available channels. 
However, when the user pauses at a particular location, 
ttie system may switch to a second resolution ttiat effec- 
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tivety decreases the position sensitivity of the slider 372 
so that the user may more easOy select a panicular 
channel within a few channels ot the position paused in. 
For example, the GUI nray actively rescale the pixel allo- 
cations in the channel/services table so that the numto 5 
of pixels allocated to channels immediately surrounding 
the cursor position is increased and the number of pix- 
els allocated to channels thai are not proximate to the 
cursor position are associated with relatively fewer pix- 
els, to 
[0086] Those skilled in the art can immediately 
appreciate that video channel tuning using the channel 
tuning bar 150 desaibed above will be highly intuitive 
and quick because users tend to make viewing selec- 
tions based on memorized channel numbers arKi call- i5 
signs. Furthermore, useis can directly select the 
desired channel for viewing without having to pass 
sequentially through all available channels, or having to 
key in a muHi-digit channel number. 

20 

b. Pop- Up Remote Control 

[0087] Another inportant aspect of the present 
invention is the pop-up remote control link 166, which 
can be selected by the user from several of the GUI 2S 
pages to invoke the dspiay of a graphic overlay that 
simulates a hand-held remote control unit Illustrated in 
FIGS. 20 and 21 are two possible configurations for the 
pop-up remote. Other configurations are possSde, and 
may be preddined so that the pop-up remote closely 30 
matches the appearance, button layouts and button 
functions of a particular type of remote control with 
which the user is familiar. For example, if the user has 
an RCA® television, a pop-up remote graphic that repli- 
cates the RCA® remote may be specified. Although the 35 
GUI of the present invention typically accepts user 
ir^juts from a PC system s keyboard or mouse, many 
users may be more comfortable with, and may find it 
more intuitive to use, the keytxjard or the mouse to 
manipulate a simulated remote control to navigate 40 
through the pages of the GUI. 
[0088] The functionality, configuration, and button 
layout of the pop-up remote may vary according to the 
service page that launched the pop-up remote control. 
This context sensitive combination of pop-up renwte 45 
appearance and associated functionality may be 
accomplished in a variety of ways. For example, the 
system may associate a plurality of graphic files and 
function subroutines using a simple data structure (e.g.. 
a lookup table, a matrix or pointers). Typically, the user so 
is presented with a pop-up remote graphic having a plu- 
rality of buttons that initiate functions that are consistent 
with, or complementary to, the content of the cun-ent 
service page displayed. When the user launches into a 
page, pop-up renvite graphk: files and function subrou- ss 
tines associated with that particular page are used to 
build both the graphic display of the pop-up renrate and 
to provide the functionality underlying the displayed 



configuration. When the user selects a location assod- 
atad with a particular buttoa the systOT may. for exanh 
prie. associate the button's position on the saeen with a 
particular block of executable code (eg., a subroutine) 
and execute that code. 

[0089] For example, the pop-up remote shown in 
FIG. 20 may be associated exclusively with video chan- 
n^ service pages, and the pop-up remote shown In FIG. 
21 may be associated exdu^vely with BOW broadcast 
service pages. Thus, the pop-up remote nay be cus- 
tomized to provide functions complementary to the 
service page that launched it. The pop-up remote's 
functk)ns for the BOW service pages preferably include 
those conmiands that are required for webpage naviga- 
tion forwand/back a page, page load/^top load, page 
printing, and he^. The renwte's functions for the Soft- 
ware Downloads service pages preferably include conv 
mands for saeen printing and helpi 
[0090] Screen locations in the GUI corresponding 
to the selectable buttons of the remote are correlated to 
executable routines. The corresponding routines, when 
executed, perform the associated control function on 
the related hardware (e.g.. video card, satellite IRD 
card), such as causing the channel selection to inae- 
ment up when a "change arrow is selected. The cor- 
relations between control routines and saeen locations 
may be contained in a selectat)le or predefined template 
foe, and the remote graphic may be contained in a 
selectable or predefined graphic file. 
[0091] A plurality of graphic files and assodated 
template files may then be provided, wherein each 
graphic corresponds to a different configuration of 
remote control device that preferably conrespond to the 
actual appearance/configuration of the remote utilized 
by one of nwny manufacturers. Typically, the user will be 
presented with a remote configuration/appearance that 
corresponds to one that they are familiar with (e.g., a 
remote which corresponds to their other equipment 
such as a televisk)n, or VCR). 

C. Receiver Station Generally 

[0092] As noted above, the GUI of the present 
invention is preferably implemented within a DTH PC- 
based satellite communication system 100 such as that 
depicted generally in FIG. 1. Discussed in more detail 
below is a preferred system and method for executing 
the GUI software of the present invention. In particular, 
a preferred receiver station 106 arcNtecture is dis- 
dosed. In addition, preferred data transmission meth- 
ods that fadlitate the GUI's abflity to receive and 
manage the large anrount and variety of digital informa- 
tion that is broadcast within the DTH system 100 are 
disdosed. 

[0093] FIG. 22 is a detailed illustration of a pre- 
fened implementation of the receiver station 106 shown 
in FIG. 1. As shown, the receiver station 106 indudes 
the reception antenna 124. the LNB 126. and the PC 
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128. The PC 128 includes the monitor 130 and the com- 
puting unit 132, which may have a modem connection 
via the PSTN to the network 122. The computing unit 
132 includes. Inter alia, a satellite receiver card 418, a 
video/audio decoder card 420. which may be integrated 
with the receiver card 418, a conditional access card 
422. a mass memay such as a hard disk (not shown), 
and processing/control capabyities such as a PC moth- 
erboard 424. The satellite receiver card 418 includes a 
tuner 426, a demodulator 428, a tbn(vard error correc- 
tion (FEC) decoder 430. and a transport functional 
processing block 432. The vWeo/audio decoder card 
420 includes a video/audio decoder 434, an optional 
NTSC and/or ATSC output driver 438, and a VGA output 
driver 436. The satellite receiver card 418 and 
video/audio circuits (e.g., video/audio decoder card 
420) perform the (unctions of receiving and decoding 
the signal received from the LNB 126. The incoming sig- 
nal is rocetved by ? s?^»'Pte r^^^^/^r ca»^d A^B -^rd 
passed through a series of initial processing operations 
including the tuner 426, the democfejlator 428, and the 
fbnward en-or correction decoder 430. before passing to 
the actual transport functional processing block 432. 
Although the functional circuits within the transport 
functional processing block 432 are not illustrated, they 
are identical to the channel derrujltiplexing, deayption, 
and access detemiination circuit btocks of a standard 
transport decoder. For example, the transport functional 
processing bkxk 432 receives the transport stream or 
bitstream of digitized data packets containing video, 
audia scheduling information, and other data The dig- 
ital packet information contains identifying headers as 
part of its overhead data Under control of the PC's main 
processor/controller (typically located on the PC moth- 
ertward 424). the transport functional processing block 
432 filters out received data packets that are not cur- 
rently of interest. Received data packets that are of 
interest are routed through decryption and access con- 
trol operations within the conditional access card 422. 
Access contirol may be provided by any known means. 
For example, access control may be achieved by requir- 
ing a data packet to have a proper authorization code in 
order to be passed to the video/audio decoder card 420. 
[0094] The transport functional processing block 
432 passes the data to the video/audio decoder 434 of 
the video/audio decoder card 420, The authorized data 
of interest are stored in system RAM (not shown) for 
buffering, and the video/audio decoder 434 retrieves the 
data from RAM as needed. 

(0095J The allocation of memory and control func- 
tions may be artaitrarily divided between the PC sys- 
tem's function cards (e.g.. the satellite receiver card 
418. the video/audio decoder card 420. etc.). Thus, a 
substantial amount, or posslWy all. of the control and 
memory functions for operation of the present invention 
may be integrated within a single card, or alternatively, 
may be incorporated within \he PC mothertxwrd 424. 
When needed, the data is routed to the video/audio 



decoder 434, which includes display drcuitry. For video 
data, the video/audio decoder 434 reads in the com- 
pressed vkJeo data from its RAM, parses it, creates 
quantized frequency domain coeffkients, then performs 

5 an inverse quantization, inverse discrete cosine trans- 
form (DCT) and motion compensation. At this point, an 
image has been reconstructed in the spatial domain. 
This image ^ then stored in a frame buffer in the vkJeo 
decoders MM, At a later time, the image is read out of 

10 the frame buffer and passed through the display cir- 
cuitry to the VGA output driver 436 and optionally, to the 
NTSC and/or ATSC output driver 438. The disptay cir- 
cuitry also generates the graphics that allow text such 
as ttie QUI electronic program guide data to be dis- 

15 played. 



D. Receivef Station Ar«hrfprh,rft 
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20 ttock diagram 500 depicting, by way of example only, a 
prefened organization of the PC's computing unit hard- 
ware and software which may implement aspects of the 
present inventioa A tuner driver 502, a TV control block 
504. a video MPEG driver 506. and a vkJeo VGA driver 
25 508 provide the major functions of a conventional Inte- 
grated receiver decoder (IRD). The tuner driver 502 
receives a di^ signal modulated on an RF carrier 
(eg., a digital satellite downlink signal) on line 510. and 
performs known IRD functions to parse out and selec- 
30 tively contifol the f tow of conditional access, video/audio, 
and MPT data streams. The tuner driver 502 passes 
selected vkleo/audio data packets to the video MPEG 
driver 506 on line* 512. The MPEG driver 506 controls 
the MPEG decoding hardware, synchronizes video and 
35 audio data, and manages the buffering of vkJeo and 
audio data to be displayed. The MPEG driver 506 
passes decoded video information to tiie vkleo VGA 
drive' 508 via line 516. The VGA driver 508 processes 
the decoded video information 514 and provides a dis- 
40 play signal tiiat may be, for example, a standard RGB 
output on line 516. The TV control block 504 controls 
tiie size and location of the video window via an MPEG 
decode control signal on line 518 and a VGA window 
display control signal on line 520 that are passed to the 
45 video MPEG driver 506 and the video VGA driver 508 
respectively. 

[00971 With respect to file data, the tuner driver 502 
passes file data (e.g., websites, software, etc.) as MPT 
data packets to a tuner NDIS driver 522. The NDIS 
so driver 522 strips the MPT header and passes standard 
IP data packets 524 using Microsoft® NDIS protocol to 
a standard Windows® Winsock® interface 526. File 
data 528 may alternatively be passed to the Winsock® 
interface 526 as IP data packets via a networi^ driver 
55 530 tfiat exchanges information with a networt< connec- 
tion 532 that m^. for example, be an Ethernet, ISDN, or 
POTS connection. 

[0098] A data manager 534 functions as a data dis- 
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tributor a data hub. The da^ manager 534 receiver 
and interprets f Oe data from Gne 536. The data manage 
534 furttier provides an optional HTTP proxy service via 
line 538. uses an SDP+ data stae 540, and.schedules 
data-felated tuning requirements. The data managa* 5 
534 may store data files (e.g.. HTML GIF. etc.) on a 
local fae system 541 (e.g.. a hard disk) via a fifth data 
path 542. 

[0099J The data manager 534 may use a TAPI 
Itorary liriock 546 to communicate via a telephony appli- 10 
cation programming interface (TAPI) via One 544. The 
TAPI library block 546 s in direct communication with a 
modem 548 having a POTS phone line connection 550. 
In this w^, the data manager 534 can report to a serv- 
ice provider which advertisements a particular user has is 
viewed or selected (i e., advertisement tracking). In 
addition, the data manager 534 comntunicates with a 
service/CA manager 552. which sets tuning priori- 
ties/controls, manages conditional access messages, 
and resolves messages relating to program tuning infor- 20 
mation that are exchanged via a third data path 554 
to/from the tuner driver block 502. 
[0100] The SOP + data store 540 is a database that 
contains all the current SDP+ record information. The 
SDP-i- data store 540 passes DPG data store queries 2s 
for data item description and cfisplay fomriatting infonma- 
tion to a data program guide block 558 on line 556. The 
data program guide block 558 contains the dynamic 
HTML pages, including graphic content that is currently 
being broadcast by the satellite communication system 30 
100. The data program guide block 558 may retrieve 
files from the local file system 541 via a fourth data path 
560. The SDP + data store 540 may also pass enriched 
TV^data store queries 562 to an enriched TV function 
564 that serves to map a channel to an IP address and 35 
a port. The enriched TV function 564 may further 
receive tuning control inforn^tion. via line 566. from a 
tuning control interface 504 and way, accordingly, pass 
screen formatting information to the TV control block 
504 on line 570. The enriched TV function 564 and the 40 
data program guide block 558 may exchange informa* 
tion with a browser application 572 along a first data 
path 574 and a second data path 576. respectively 
[0101] As described in section IV.B.3^. of this dis- 
closure, a user may interact with the GUI to schedule 45 
the download of file data. The GUI utilizes SDP + 
records to perform this task. The SDP + records are 
stored in the SDP 4 data store 540. At the scheduled 
time of reception, the data manager 534. which holds 
schedule information, examines the records in the SDP so 
+ data store 540 to determine the multicast IP address 
on which the download will be broadcast. After the data 
manager 534 has detennined the multicast IP address, 
the service manager 552 looks to the BARP taWe. 
which may be stored on the kx^al file system 541. to 55 
determine tuning information for the mufticast IP 
address found in the SDP+ record. For example, a 
broadcast of Quicken *98™ software may be broadcast 



on multicast IP address 1Z3.4 and that muttica^ IP 
address may con-espond to hming intormation indicat- 
ing transponder two SCID five, according to the BARP 
table. Once the tuning information is d^&mned. it ^ 
passed to the service/CA manager 552, which tunes the 
tan& driver 502 to. tor example, transponder twa SCID 
five. 

[01 02] File infonnfiation received by the tuner 502 is 
passed to the tuner NDIS driver 522, where it is con- 
verted into IP data and passed to the Winsock® 526. via 
line 524. The Werrsock®. in turn, passes the IP data to 
the data manager 534. which patorms the 6FDP func- 
tion on the IP data to recover the data for Quicken 38™. 
The data associated with Quicken *98™ is stored on the 
local file system 541 for later use. Any data determined 
by BFDP to be missing from the received Quicken '98™ 
fae will be obtained on sut^sequent broadcasts of the 
fde. When the complete file has been stored on the local 
file system 541 . Quicken *98™ is complete and ready to 
run. 

E. Pata Pachflts 

[0103] FIG. 24 is a diagram illustrating a pretended 
type of transport data packet tfiat may be transmitted via 
the system 100 shown in FIG. 1 and processed by the 
receiver station 106 shown in FIGS. 22 and 23. More 
specifically, the data packet may be coupled to the 
recaver station shwn in FIG. 23 via line 510. The pre- 
fened data packet shown in FIG. 24 is in the format and 
of the type used in the DirecTV® dgital broadcast sys- 
tem. As shown, each data packet may be. for example. 
147 bytes long. The first two bytes (a byte is made up of 
8 bits) of infonriation contain the SCID and f^gs. As 
previously stated, the SCID (senrice channel ID) a 
unique 12-tMt number that uniquely identifies the 
packet's service channel. The flags are made up of four 
bits used primarily to control whether or not the packet 
is encrypted and. if enaypted. whk;h key to use to 
decrypt the packet The third byte of information is 
made up of a tour-bit packet type indicator and a tour-bit 
continuity counter. The next 127 bytes of infornration 
consists of the "payload" data, which is the actual usa- 
ble infonnation sent from the program provider. The 
paytoad can be any of the various types of data sent 
over the airiink, including video, audio, conventional pro- 
gram guide data, data related to the layout^nrtaVcon- 
tent of the user interface display pages of the present 
invention, conditional access data, webcasting data, 
software download data. etc. 

R Audio/Vicleo Processing 

[01041 The architecture shown in FIG. 23 may be 
used to receive audio and video signals associated with 
television programming. When a user desires to watch 
television programming, the service/CA nranager 552 
tunes the tuner driver 502 to the appropriate trans- 
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pond^ and SCID or SCIDs to receive the appropriate 
programming signata Hie received signals are passed 
to the MPEG video driver 506 via line 512. The MPEG 
video driver 506 appropriately processes the received 
signals to obtain aidio and video signals that are 
passed to the video VGA driver 508, which, in turn, 
passes the signals to a monitor for display. 

G. Data Processing 

1. PrOtOCQl StacK/Brcadoast File Downiflari Pr^^i 
(BFDP) 

10105] As discussed in section IVA. of this disclo- 
sure, the GUI of the present invention requires the pres- 
ence of appropriate data at the receiver station 106. 
Although a variety of data processing techniques could 
be used in conjunction with the GUI of the present 

preferred data processing methods. Respectively, these 
methods provide a way of r etiat>ly Iransfemng file data in 
a one-way communication channel, resoMng IP 
addresses into physical addresses, and announcing to 
the receiver station 106 how to display available data 
streams lor selection, and when and how to tune to data 
streams selected by the user. 
101 06] Illustrated in FIG, 25. is a preferred data flow 
through a protocol slack that utilizes the BFDP. BARP, 
and SDP + data processing methods. The transmission 
station 102 (or "headendT builds transport data packets 
for transmission in accordance with the headend data 
flow arrow. There are four primary data flow paths 
through the protocol stack at the transmission station 
102. File data begins at an application layer 602 and is 
passed down through a BFDP layer 604, a UDP layer 
608, an IP layer 610. and is encapsulated for transmis- 
sion to the receiver station 1 06 by an MPT layer 61 4 and 
a transport layer 616. Webcast data begins at the appli- 
cation layer 602 and is passed down through a webcast 
l£Qrer 603, the BFDP layer 604. the UDP layer 608. the 
IP layer 610, the MFJ layer 614. and the transport layer 
616. SDP+ records begin at the application layer 602 
and are passed down through an SDP+ layer 606, the 
UDP layer 608. the IP layer 610. the MPT layer 614 and 
the transport layer 616. BARP information begins at the 
application layer 602 and is passed down through a 
BARP layer 612. the MPT layer 614 and the transport 
layer 616. Transport packets received at the receiver 
station 106 (or "subsaiber") are resolved into BARP 
information. SDP + records, webcast information, and 
file data by passing the received packets up through the 
protocol stack in the direction indicated by the sub- 
scriber data flow arrow. 

[0107] Ulustrated in FIG. 26 is an exemplary method 
of processing a data packet using the protocol stack 
shown in FIG. 25. FIGS. 25 and 26 are descrtoed is 
more detail below in connection with in-depth discus- 
sions regarding the BFDP. BARP, and SDP+ data 



processing methods. 

[0108] As discussed earGer in section iV.B. of the 
disclosure, the GUI of the present invention fadlitates 
the organization, selection, and display of audloAndeo 

5 information, file data (e.g.. software, websites, etc.), and 
streaming data (e.g.. data tickers). For exan^le. the 
Software Downloads data service 240 (shown in FIG. 8) 
allows a user to schedule autonDatic downloads of soft- 
ware titles to the PC 128. and the BOW data service 

10 200 (shown in FIG. 4) alkTws a user to select websites 
for periodic/regular downloading to the PG 128. 
[0109] Downloading tae data is especially diffkxm 
within the DTH system 100 (shown in FIG. 1) because 
the DTH system 100 does not provide a backchannel 

15 communication path from the receiver station 106 to the 
transmfesion station 102 (i.e., the communication path 
is a one-way path to the receiver station 106). The 
absence of a backchannel makes tt impossWe for the 

20 Station 102 that a software fQe was oonpletely received 
and error free. Additionally, the absence of a backchan- 
nel prevents the receiver station 106 from requesting 
rebroadcast of ntissing data from the transmission sta- 
tion 102. Although the communication channel associ- 
25 ated with the DTH system 100 has a very low bit error 
rate, relatively long periods of signal intenxiption may 
occur. For exanple, snow or rain, eitiier at the transmis- 
sion station 102 or tiie receiver station 106 may cause 
the communication channels of the system 100 to fade. 
30 thereby causing received signal errors. Additionally! 
user activity, such as receiver station tuning or deactiva- 
tion, may cause signal inten^ptions. If signal interrup- 
tions occur during the download of file data, the file data 
will be incomplete and inoperable. 
35 (01 1 0] One prefen-ed method of addressing ttie dif- 
ficulty associated with transmitting fie data along a one- 
way communication path, such as that used by the GUI 
ol the present invention, uses data carousels at the 
transmission station 102 that repeatedly broadcast the 
40 same file data to tiie receiver station 1 06 in conjunction 
with a data transfer protocol that is the subject of a co- 
pending, commonly assigned patent applk^tion serial 
"lo. f iled on and 



entitled 



The Broadcast File 



45 Download Protocol (BFDP) prepends a header to the 
f fle before transmission of the data packets. This header 
allowvs a download fle to be reassembled from informa- 
tion received during one or more broadcasts of the 
same download file. Thus, if some file data is lost or cor- 
50 rMpted during a first broadcast of the download file. 
BFDP allows the receiver station 106 to lill in" any 
missing or corrupted file data with file data received dur- 
ing a subsequent broadcast of the same download file, 
thereby avoiding the constraint of having to receive an 
55 entire file witiiout corruption/inten-uption during a single 
broadcast 

10111] The details of BFDP will now be explained 
witti reference to FIGS. 25 and 26. If a file (eg., a web- 
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she. a software file, eta) is to be broadcast from the 
trar^smisstc^ station 102 to ttte receiver station 106, 
data from the apptication layer 602. such as webcast is 
passed to the BFDP layer 604. For purposes of expla- 
nation of the BFDP, it will be assumed that a data file 5 
620 having 2 kilobytes (2K) of data is to be transmitted. 
The data tde 620 is received by the BFDP layer 604. 
which It necessary, breaks the data file 620 into smaOa' 
data fragments 622 and ^4. For purposes of explana- 
tion It is assumed that the data file 620 is split into two w 
1K data liagments 622. 624 and that a BFDP header 
626 ts prepended to each of the cteta fragments 622. 
624. The sue of the fragments is a tradeoff between 
overhead and the probability of date loss. If low over- 
head is desired, the size of the data packet will be large 15 
with respect to the BFDP header on the data. However, 
if the probability of data loss is high, the size of the data 
packets should be made smaD to minimize the data lost 
if a single packet Is lost. Typically, the protjability of data 
loss is determined by channel characteristics. The 20 
remainder of the processing for each fragment is identi- 
cal. A santple format for the BFDP header 626 is shown 
in FIG. 27. 

[01 1 21 The eight fields of the sample BFDP header 
626 provide information concerning the number and 25 
order of the data fragments 622. 624 that are broadcast 
to nvike up the data file 620. Each field in the sample 
BFDP header 626 is r^resented by four bytes, except 
for filename, which is represented t)y sixty-four bytes. 
The Sync, field contains information that may be used to so 
assist in identifying the header. An ID field is a represen- 
tation of the object ID for the file being broadcast. The 
object ID may be used for data f iltertng at the receiver 
station 106. The Version field indicates the version of 
the BFDP used to create the present packet Filename 35 
is sixty-four bytes of information used to indicate the 
filename and path where the data fragment is to be 
stored on the receiver station 106 (e.g., C:\down- 
loads\xyz). Preferatsly. the filename field is used only for 
special files and is not generally used. For example. 40 
when webcast information is transferred, a HTTP 
header is used and the filename field is ignored. The 
Modified fiekl denotes the last time the fragment was 
modified. Preferably, this representation is in UNIX 
timej formal. Count, Number, and Size fields refer to 45 
the number of fragments used to make up the original 
file data that is broadcast, the number of this fragment, 
and the size of this fragment, respectively. The count, 
number, and size fields are key pieces of information 
that allow BFDP to reconstruct a complete data file from so 
multiple broadcasts of the data file. For example, a data 
file may be broken into 10 fragments and. during trans- 
mission, fragments 1-5 and 8-10 were received by the 
receiver station 106. On subsequent broadcasts of the 
data fBe, the receiver station 106 examines all of the ss 
BFDP headers on the received fragments and only 
stores the data packets indicated as fragments 6 and 7 
in their. BFDP headers, thereby filling in the received 



data file. 

[0113] As shown in FIGS. 25 and 26. after the 
processing complete at the BFDP laya 604. the 
resulting data packet Is transferred to a UDP \ay& 608, 
which prepeids a UDP header 628 to the packet The 
UDP header 628, which is standard and wefl known in 
the art. is shown in FIG. 28. The UPD header 628 
includes fields that denote source and destination ports 
for the data. That is, UDP header fields contain informa- 
tion incficating the application that is providing the data 
(source port) and the application that is to receive the 
data (destination port). At this point in the processing, 
the data packet is referred to asa UDP packet 630. 
[0114] Data transfened to a computer through a 
connectton is typically in an Internet protocol (IP) for- 
mat. whk;h is well known to those skilled in the art. 
Accordingly, the UDP pack^ 630 is passed to the IP 
layer 610. which in a welt known ntanner. prepends an 
IP header 632 onto the UDP packet 630. thereby creat- 
ing an IP packet 634. The IP header 632; which is 
shown in FIG. 29 denotes, inter alia, the IP addresses of 
the data source and destination computers. Information 
that is broadcast to a number of users preferably uses a 
multicast IP address. Alternatively, information may be 
addressed to specific users via a standard IP address. 
[01 15] After the UDP packet 630 has been property 
processed by the IP layer 610 to create the IP packet 
634. the IP packet 634 is passed to an MPT layer 614. 
The MPT layer 614 processes the IP packet 634 to ere- 
ate an appropriate number of MPT packets 636. For 
example, in digital video broadcasts (DVB) the size of 
the MPT packets may be 185 bytes. Alternatively, the 
MPT packets may be 127 bytes long for other direct to 
home (DTH) applicattons. For use in the present system 
20. each the MPT packets 636 is 1 27 bytes tong includ- 
ing a header and data. The MPT layer uses a number of 
packet configurations, shown in FIGS. 30A - 30D. to cre- 
ate the 127 byte packets. If the IP packet 634 contains 
1 1 4 bytes or less, only one MPT packet refened to as an 
"Only Packet" 760 needs to be created. The preferred 
format of the Only MPT packet 760 is shown in FIG. 
30D. The Only packet 760 includes: a six t}it flag fiekJ 
that is preferably reserved and set to all zeros, a one t»t 
start of frame (SOF) field that indicates that this packet 
is the start of the frame, a one bit end of frame (EOF) 
field that indicates that this packet is the end of the 
frame. If the IP packet 634 contains 1 14 bytes or less, 
only one MPT packet 636 will be sent, therefore the 
Only packet header indicates that the Only packet 760 
is the start of the frame and the end of the frame. The 
Only packet 760 may also indude a field indicating the 
sub-SCID address of the packet, which prefOTWy 
includes a two byte type code and a four byte type- 
dependent code Preferably, the type code is 0x0100. 
which signHies that the last four bytes are the multicast 
goup address to whk^ this frame belongs. The Only 
packet 760 may also include a frame type field, which 
identifies the type of content in the MPT frame. Prefera- 
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biy, this field is used to indicate whether the frame is an 
IP frame or a BARP frame. Preferably, the frame type 
field is faied using Internet Assigned Number Authority 
(lANA) standard numbers. Further, the Only pagket 760 
may include a cyclic redundancy check (CRC). which is 5 
a 32-brt number computed over the entire MPT frame. 
[0116] If the IP packet 634 Is to be processed by the 
MPT layer 614 is longer than 1 14 bytes. Start 730. Mid- 
dle 740 . and End 750 MPT packets shown in FIGS. 30A 
- 30D are preferably used to process the IP packet 634. 10 
The headers of these packets use all combinations of 
the f iekJs described in conjunction with the Only packet 
760. As shown in FIG. 26, the frst 1 18 bytes of the IP 
packet 634 are toaded into the MPT Start packet 730. 
The start header of the MPT packet denotes a MPT 15 
packet as the start of the frame by setting the SOFfcwt. If 
the IP packet 634 is larger than 244 bytes the appropri- 
ate number of Middle packets 740 will be filed with 126 

cpr+;(>ns r^4 Hn+n 4Tf^rr^ tHp \0 r;;:^^^ $04 T>« C/->C 

and EOF bits will not be set because the MPT packet is so 
a middle packet Numerous middle packets will be filled 
with the IP data until there is less than 122 bytes of data 
remaining in the IP packet 634. At this point an End 
packet 750, is filled with the last bytes of information and 
appended wrth a CRC. This method of using Only, Start. 25 
Middle, and End packets yields MPT packets that are all 
exactly 127 bytes long. 

[0117] After each IP packet 634 has been con- 
verted to one of the MPT packets 636, each of the MPT 
packets 636 is passed to the transport layer 616. The 3o 
transport layer 61 6 places each 127 byte packet into the 
127 byte payload section of a transport data packet 
(shown in FIG. 24). The conplete transport data packet 
is passed to the uplink frequency converter 1 18 of FIG. 
1 and broacteast to the receiver station 106. 35 
[0118] As the receiver station 106, which is tuned to 
a particular transponder and SCID, receives packets of 
infomiation. the data packets traverse up through the 
protocol stack as indicated by the subsaiber data flow 
indicated on FIG, 25. The transport layer removes the 40 
payload from each transport packet. After the appropri- 
ate processing, the payload Is passed to the MPT layer 
614, which strips the MPT header ffom the packet and 
assembles all relevant data from MPT packets to 
assemble the IP data frame. The IP layer 61 0 strips the « 
IP header 632 from the data, performs well-known IP 
processing functions, and routes the data to the UDP 
layer 608. The UDP layer 608 strips off the UDP header 
628 and routes the remaining information to the proper 
application (port) as denoted by the UDP header. The 50 
BFDP layer 604 strips the BFDP header 626 from the 
data packets and, using the information in the headers, 
reassembles the data contained in the BFDP packets 
into the data file 620 as sent by the transmission station 
102. Additionally, if necessary, the receiver station 106 
denotes missing data packets through examination of 
the BFDP headers. Thus, the GUI of the present inven- 
tion may reassemble the original data file in accordance 



with the BFDP header fieWs at the receiver station 108 
after multiple broadcasts of the original data file. That is, 
any missing data after the data is broadcast wil be 
lilled in" with the appropriate data from subsequent 
broadcasts of the original data a file For example, if a 1 
megabyte (MB) f ae is broadcast and the receiver station 
106 successfully acquires all but 1 kik)byte (KB) of the 
broadcast information, instead of having to reacquire all 
of the data that the receiver station t06 has already 
received, ttie receiver station 106 simply waits for and 
acquires the 1 KB of data that it needs to complete the 
1MB file. 

2. Broadcast Address RPsnl ^tion Protocol (BARP) 

[01 19] As referenced earlier, the broadcast address 
resolution protocol (BARP) layer 612 is required to 
resolve IP addresses into physical (i.e., satellite trans- 
'**"^} '^r'd'Csrcs. <- *^*'^ct of ^ -^,-1.. 

ing commonly assigned application entitied 

, filed on_ and 

bearing serial no. I The BARP 

layer is coufrfed to the MPT layer 614 and is used to 
map a multicast source IP address to transport-specific 
tuning information. That is, BARP is a map that tells a 
receiver station 1 06 on which transponder or transpond- 
ers and SCID or SCIDs. information from a particular 
source IP address may be found. For exan^e. when a 
user selects information from the GUI. tiie receiver sta- 
tion 106 uses BARP to determine tuning parameters 
(e.g.. transporvJer and SCID) for the information 
selected by the user. Preferably, BARP informatron is 
periodically sent on as many transponders as possible 
so ttiat users have easy access to the most current 
BARP information. 

[01201 BARP consBts of a header followed by zero 
or more address records. BARP preferably uses MPT 
frame type 0x0806. FIGS. 31A and 31B represent the 
fomiat of a BARP header and a BARP address recad. 
re^ectively. The BARP header includes version! 
change number, record count and reserved fields, in 
this example, version is a 1 byte f leW that represents the 
version of tiie BARP format used to aeate the header 
and address record. Qiange number is a 1 byte field 
that is incremented each time anything in the header or 
any of tiie address records change. Record count is a 2 
byte field tfiat indk:ates tiie number of address records 
that follow this BARP header. The resented field is a 
four byte field that may be used to provWe system flexi- 
bility in the future. 

[01 21 ] The BARP address record, as shown in FIG. 
31 B. includes six fieWa An IP address field contains a 
four byte representation of an IP address. Transponder 
is a bitmap fiekJ identifying the transponders on which 
the previously-noted IP address can be found. Each bit 
in the transponder fieW conresponds to a transponder. 
Set bits in the transponder field indicate the presence of 
the IP address on that transponder. For exanple, if the 
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first bit is set (1 ) and the rest of me bits are dear (0) then 
the IP address Gsted in the tP address ftetd is present 
only on the frrst transponder of the sy^ent The SCID 
field denotes the 12 bit SCID that contains the tnfomna- 
tion provided by the IP address l^ed in the first field of 
the header. Preferably, the four most significant bits are 
reserved. Channel is 10-bit channel number that is 
associated with the this SCID and transponder. For 
example, transponder two. SCID nine may con-espond 
to channel 105. Preferably, the most signricant 6 ttts of 
the channd fieid are reserved for future usa Service 
type is the type arKl paradigm of the channel associated 
with the transponder and SCID in the address record. 
The reserved field is 3 bytes long and is preferably 
reserved for future system usa Information for channel 
and service type fields are preferably supplied by the 
broadcaster to satisfy tuning requirements of subscriber 
units. 

[0122] While the BARF and BFDP protocol layers 
represent one preferred way of tran^itting the informa- 
tion related to the GUI of the present invention, other 
transmission systems and methods may be suk>stituted 
without departing from the spirit of the invention. 

H. SDP + Records 

[0123] Another difficulty faced in utilizing the wide 
variety and large amount of information transmitted 
within the DTH system 100 is providing a way for the 
GUI to efficiently find and process the various kinds of 
data that are available at various times within the multi- 
program data stream. One preferred method that allows 
the GUI of the present invention to efficiently find and 
process infonnation for presentation to a user are 
"session description protocol plus" (SDP +) 
records. SDP+ records are the sut^ect of a co- 
pending commonly assigned application entitled 

, f fled on and 

bearing serial no. / . 

[01 24] An SDP 4 record is an announcenrient mech- 
anism that includes a number of fields, which are 
assemt)led into a single record or file to provide infonna- 
tion on available sen/ices such as webcasts, dowrv 
loads, and streaming data or other services. The SDP + 
protocol is a combination of standard SDP fields and 
augmentations, or extensions, to the standard SDP pro- 
tocol. Additional details regarding the standard SDP 
protocol may be found in RFC 2327. The standard fields 
of the SDP protocol that are used in the of the SDP + 
protocol include, protocol version, the owner/creator 
and session identifier (i.e.. the IP address of the creator 
of the SDP record), the name of the SDP session (i.e.. 
the name of the SDP record), a brief description of the 
sesson (i.e.. what the SDP record is for), the multicast 
address on which the session is being broadcast, the 
start and end times of the broadcast, the repeat times of 
the broadcast a list of Internet webpages that can pro- 
vide additional information on the item that is going to 



be broadcast what the port of the broadcast is (i.e. the 
UDP port of the broadcast), the type of broadcast (e.g.. 
BFDP. Stream. Webcast or Interca^), sorting and filter- 
ing information. 

5 [0125] As noted, an SDP record may also contain 
information such as the time a particular service will be 
broadcast the multicast IP address on which the serv- 
ice win be broactoast. the size of the ftle that wOl be 
broadcast and information relevant to the GUI &ich as 

70 text or images that should be dsplayed to the user. 
Each download service (eg., eac^ webcast each soft- 
ware download, etc.) has its own SDP ^ record, which is 
broadcast to all subscribers to inform (hen of the infor- 
mation that is available for download. With reference to 

IS GUI infonnation. SDP -i- r«x}rds are used t>y the PC 1 28 
to build particular sections of pages using selected 
infonnation reskjent within the PC 128 (e.g.. the basic 
page template 180) and selected dynamic data that is 
received from a sat^lite in the form of SDP + records. 

20 When the user launches the interface into another state 
Of page, the GUI builds the destination page as 
instmcted by the template 180 and by the SDP + 
records. The page is then displayed on the user's PC 
morntor 130. 

25 [01 26] SDP + records also allow users to pre-select 
download content from descriptions of the content, then 
f 9ter for that information as it arrives in the one-way data 
stream of the DTH system 100. The descriptions of the 
content may include extended SDP records including 

30 protocol version, name, times of broadcast IP address, 
mandatory download status, ID number, run command, 
category, file size, text messages, channel, images, 
keywords, etc. 

[0127] As previously mentioned, SDP -i- records 
35 also provide announcement inforrration irK:luding con- . 
tent type, start time, duration. Internet address informa- 
tion, and actions to be taken on recdpt of the 
information. Announcement management is critical to 
finding the data stream, disaete download or webcast 
40 information in the received transmission. SDP + records 
can be rescinded and modified, once they are present 
on the user's PC 128. SDP -f records can be used to 
indicate mandatory download events such as software 
updates. The system user (client) uses SDP + records 
45 to schedule program reception. After the client makes 
selections based on the SDP -i- record information, the 
receiver station 106 properiy tunes itself to receive the 
selected information. 

[01 28] SDP + recads are a combination of conven- 
so tional SDP records and extensions to the conventional 
SDP records. Generally, the extensfons to the standard 
SDP protocol consist of fields for linking different down- 
load services together, specifying if a download file is 
mandatory, archived or should be run upon download to 
55 the receiver station 1 06. The extensions also provide for 
specification and placem^ of graphics for the GUI. the 
notification of the user upon receipt of the SDP + record, 
and the recission of previously sent SDP ^ records. 
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These unique extensions coupled with the standard 
SDP protocol yield the SDP + protocol used in corijunc- 
tion with the GUI of the present irvention. The details of 
the conventional SDP fields and the unique extensions 
of the present invention are best described in conjunc- 
tion wrth the exemplary SDP + records shown in FIGS. 
32A-32D. 

(0129J Referring now to FIGS. 32A-32D, fields Indi- 
cating version (v). record ID (o). multicast IP address 
(c). time (t). and port (m) are required for all SDP + 
records ol any k»nd. Additionally, for any BFDP down- 
load the object ID BFDP code (a = key:) is needed. The 
run command (a=run:) is required for all streaming data 
downloads. For all streams having an entry in the MPQ 
a channel link (a = channel) is required. Additionally, for 
all webcasts a URI address fietel (u= ( uri )) is required. 
[0130] FIG. 32A « a sample SDP + record for 
streaming data, which is commonly referred to as a 
t;^..-., Tyy^ v3rsrcn of ths SDP + 

protocol used to produce this SDP + record. The record 
ID. which is represented by 'o," indicates the unique 
session ID for this particular record. Specifically, the 
session ID for this SDP + record is 0001 and the version 
of this record is 17. The session ID is a way to refer to 
this particular SDP + record and 1 7 indicates that there 
have been 16 previous versions ol thfe SDP + record 
before this version. The name of this session is repre- 
sented by "s = Announcement Dump." However, it 
should be noted that the session name is arbitrary 
ASCII text that is used to identify the SDP + record. The 
field "c" represents the multicast IP address of this ses- 
sion and "/r indicates that the Time To Live (TTL) 
value, which indicates the number of "hops" that a 
packet may make before it expires. Multicast IP 
addresses denote the IP address on which the informa- 
tion corresponding to the SOP + record vwll be broad- 
cast The multicast IP address is used in corijunction 
with the previously desaibed BARP table to tune a sub- 
saiber's receiver station 106 to ttie appropriate trans- 
ponder and SCID to receive the broadcast information. 
When a user makes a request to receive broadcast 
information using the GUI. the receiver station 106 
determines the multicasi IP address on which the infor- 
mation will be broadcast by looking to the SDP + record 
con-esponding to the selection. Once the multicast IP 
address is determined, the receiver station 1 06 uses the 
BARP table to conelate the nuiHicast IP address to a 
transponder and SCID, The receiver then appropriately 
tunes itself to the proper transponder and SCID to 
receive the broadcast information. Since streaming data 
or tickers are always running, the start and end times 
represented by 1 = 0 0" indicate that the data service is 
constantly running and is permanent. The field "m =" 
indicates that the UDP port of the data is 3278 and the 
type of data is streaming data. 
(01311 The SDP+ record shown in FIG. 32A 
includes "a=key:1 which indicates that the object ID for 
this SDP 1. record is 1 . The object ID may be used for 



sorting or other functions. The object ID in the SDP + 
record matches the object ID sent in the BFDP header. 
The field "a = run: consoletfoker" indicates that when the 
download Is complete, an executable f Oe named conso- 
5 leticker shouki be started. The standard SDP field "a = 
keywds" is used to correlate SDP records to one 
another. For example, in the SDP + record shown n 
FIG. 32A tsetup" is used to correlate this SDP + record 
with another SDP -i- record, such as a client download 
10 file. 

[01321 FKa. 32B is an example SDP + reooid for a 
file download. Similar to the ticker SDP + record of FIG. 
32A, the file downfoad SDP + record a file download 
specifies the version of the SDP + protocol used to pro- 
15 duce the SDP -i- record, the record ID. the name of the 
session, the multicast IP address of the session, and 
the ot^ect ID of the session. AdditionaSy. the SDP-f 
recofd showwi in FIG. 32B specifies dowvntoad times 
':z''^2 3 30793S?'^00 S^Sf?"*? TCO/ Ihz first 

30 number is the start time of the broadcast and the sec- 
ond number is the end time of the broadcast The start 
and end times are specified in decimal network time 
protocol (NTP) format. The "r» 1 0m 1 0m 0" specifies the 
broadcast repetition of the broadcasts, wherein the f hst 
25 number indicates the interval between broadcasts, the 
second number indicates the duration of the broadcasts 
and the third number indicates the time offset between 
the broadcasts. The field "m indicates that the UDP 
port of the data is 3335 and the type of data is BFDP 
30 data. The SDP + record shown in FIG. 32B further spec- 
ifies the size of the file that ts to be downloaded using 
the "asfsz" command. The example file dovmload SDP 
+ record specifies a file size of 980K. The file download 
SDP -I- record also specifies that this file is a mandatory 
35 downfoad using the command "a = mandatory." That Is. 
the receiver station must receive the data broadcast 
corresponding to this SDP + record during one of the 
broadcast times. The fieW "a = run:cataloginstall.exe" 
specifies that after the data associated with the SDP + 
40 record is received, the file cataloginstan.exe must be 
executed. 

[01 33] FIG. 32C is an example of an SDP + record 
that is used to specify information pertinent to a web- 
cast In addition to using the fiekfs previously described 
45 in conjunction with the file download and ticker SDP + 
records, the webcast SDP + record may use the session 
description fieW denoted as "i This fieW is an ASCII 
text f iekf that may be used to describe the content of a 
particular session or webpage. The session desaiption 
so field may be used as the preview description repre- 
sented as horizontal lines in the child window 234 of 
FIG. 6, Alternatively, the session description fiekf of the 
SDP -1. record may be used in conjunction with SDP + 
records other than webcast SDP + records. For exam- 
55 pie. the session descriptim field may be used in ticker 
SDP + records to fill in the data channel description 308 
as shown in FIG. 1 1. The webcast SDP + record also 
includes a field denoting the URt of the webpage that is 
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broadcast The w^xast SDP -f record ateo uses the 
standard SDP extension *a = cat/ which is used tor 
sorting and f dtering the SDP records. 
[0134] The webcast SDP record uses the unique 
extension 'a = dtsplaylype =' to rncHcate hCMv the infor- 
mation content from the w^x^ast win be displayed to the 
user. Additionally, the unkjue SDP + ftekJ "a = img' is 
used to associate an image file (in the case cnn.grf) with 
a webcast. TT^ image may be used as a thuntfmail or 
any other r^resentation of the content of the wdbcast 
The image field and the display type field can wor1< 
together to provide intormation for the GU 1. Display type 
may be used to indicate on wht^ page ctf the GUI the 
image specified in the image field must be placed. For 
exan^e. type may be used to specify Top 10 Webcasts, 
nomial. Top 5 Downloads, Special Events, Ticters. Soft- 
ware Hot links or Software Specials, each of which may 
be represented by a number. As shown in FIG 33C, type 
= 1 is Specified, which may correspond to Top 10 Web- 
casts. Accordingly the image cnn.^ will be placed on 
the control panel 184 of the GUI as shown in FIGS, 5-7. 
Alternatively, type rr^y indicate Top 5 Downloads, which 
corresponds to the control panel 1 84 shown on the Soft- 
ware Downloads page in FIG. 9. The specification of pri- 
ority =8 denotes the particular location in which the 
cnn.gif image will be placed on the control panel 184. 
Refening to the control panel 184 shown in FIGS. 5-7, 
different priorities correspond to different locations in 
the anrangement of the 10 Best-of-Web images shown. 
For example. Discover is priority 1, Rolling Stone is pri- 
ority 2, Forbes is priority 3. etc. 
[01 35] FIG. 32D is an example of an SDP -i- record 
that may be used to represent enriched TV In addition 
to the field discussed in conjunction with the SDP -t- 
records, this SDP + record includes the field "a ^^chan- 
nel." This field contains a 32-bit channel number that 
associates the data contained in the enriched video to 
chann^ conteit of a channel located in the program 
guide. The intbrmation contained in the enriched TV 
may be associated through a number of program guide 
channels. 

l. Wdxast 

[0136] As previously noted, the DTH system 100 
broadcasts disaete downloads. These downloads are 
data items that have well<jefined broadcast schedules 
and require detailed announcement Irrformation to 
locate the items in the received data. Examples of dis- 
crete downloads include software applications, such as 
spreadsheets, word processors or games. Webcasting 
is a special case of the disaete download. A webcast is 
an ongoing and repeating download of specially 
selected w^ content The content is usually grouped 
by domain. Minimal scheduling is required for down- 
loading webcast information. Muttipte ^oups of content 
may be id^itified by the same identifier, thereby aeat- 
ing a one-to-many relationship among the items of inter- 



est The system 100 may archive webpages pages ona 
the PC 128 for later viewing. 
[0137] As webpage information is received by the 
sut)scra>er unit it stored for later use. In the preferred 

5 embocfim&it webpage information is received in a com- 
pressed format and is stored directly (l.e., without 
extraction) by the 8ubscra>er unit Preferably, the 
present invention uses an archiving scheme based on 
the PKWare™ PKZIP™ fonnat. However, other alterna- 

10 tive archiving formats may be used. If the archived files 
are compressed, the files are preferattly extracted on 
dentand using a PKWare"* extractor. If. however, the 
fies are not compressed, any ZIP extractor may be 
used to extract and view the files. Preferatrty, the f ilena- 

15 mes used in the webcast archive are actually the uni- 
form resource identif iw (URl). 
[01 38] Prelerabty, webcast archive files have a ded* 
icated filename extension. On any given data carousel, 
the contents of which is repeatedly broadcast, there 

20 ntust be exactly one main fae for each webcast Prefer- 
ably, this fBe contains a snapshot of the entire w^^e or 
website subset as selected for broadcast Update 
archive files may be used to replace portions of the 
main file on the carousel. The subscriber unit stores all 

25 archive files in a subdirectory corresponding to the ses- 
sion ID of the webcast Preferably, when a main file is 
received that is newer than the cuaent main file in that 
directory, all other f Bes in that directory will be removed 
and any links in the proxy server's cache nrap file for this 

30 webcast will be replaced with the URIs in the new main 
fO& 

[01 39] In accordance with the present invention, the 
subscrber unit prefa-ably maps uniform resource loca- 
tors (URIs) to archive fOes. The map allows the sub- 

35 scriber unit to locate the archive file containing a URl 
that the user desires to view. When the subscriber unit 
receives the main f9e, the sutisaiber unit removes all 
f^es and cache map file links to the associated session 
prior to the receipt of the new main f fle. When the user 

40 requests a webpage. the siAscriber unit extracts and 
decorrpresses the appropriate archive fOe data to a 
socket. This extraction is done in real time rather than 
extracting the entire archive file to disk. The sut>scr&er 
unit also preferably has the capability to save partlaOy 

45 downloaded files and acquire missing portions of the 
files on the next broadcast of the fOes as with all BFDP 
deliveries. 

[01 40] In accordance with the present invention, the 
headend unit is capable of manipulating the archived 

so files using functions that archive fSes. determine the 
nurrfeer of files in an archive file, return the name of a 
particular entry in an archive fOe, remove csntries from 
an archive file, and merge a number of archive files into 
one archive file. The function that puts entries into an 

55 archive file includes a f leM denoting the file or files to be 
archived. Preferably, wiklcard indicators may be used to 
specify a numt>er of filenames tor entry into the archive 
f9e. The archive function ateo preferably allows for a 
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specification of a tocation to which the archive fOe 
should be written (e.g., a path name). In a prefen^ed 
embodiment the archive function allows for specification 
of compression or no compression for the archived f iie. 
The archive function parses the specified files, reads 
the hypertext transport protocol (HTTP) header, and 
archives the specified files to an output file using the 
URI found in the HTTP header 
[01411 A function that counts the number of ffles in 
an archive is also preferably implemented at the head- 
end mil This function allows for a specification of an 
archive faename and returns the number of files stored 
in the archive f He. Another desirable function is that of a 
function that returns the name of a file located In an 
archive file. This function allows for spedTication of an 
archive filename, the index or location of the file in ques- 
tion, the name of a buffer that will be filled with the name 
of the fOe in question, and the size of the specified 

eraWy returns the name of the file located in the speci- 
fied index position in the specified archive fBe. the size 
of the file, and the length of the character string returned 
in the buffer size. 

[0142] A function that erases portions of an archive 
file is also desirable. This erasing function allows for the 
spedffcation of the archive file in question, the array 
index or indices to be erased from the archive file, and 
the number of elements specified in the index or indices 
to be erased. Preferably, a function is included that 
allows for the merging of two archive files. This merging 
function allows for the specification of two archive file 
names. One of the archive filenames is the f «e that Is to 
be merged into the archive file bearing the other speci- 
fied filename. 

J. Conclusion 

[0143] Of course, it should be understood that a 
range of changes and modifications can be made to the 
preferred embodimem described above It is therefore 
intended that the foregoing detailed description be 
regarded as illustrative rather than limiting and that it be 
understood that it is the following claims, including all 
equivalents, which are intended to define the scope of 
tliis irrvention. 



Claims 



A conrrputer based graphical user interface for facil- 
itating the selection and display of transmitted 
audio, video, and data, comprising: 

a main menu state with a first multi-segment 
display, the first multi-segmenl display having 
an active video/audio segment, and a tuning 
segment; 

the active video segment adapted to display a 
currently tuned program: and 
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20 



the tuning segment having an elongated 
graphic bar with a length and a width, the 
length of the graphic bar being sub^ltvided into 
a plurality of contiguous regions so that each of 
the regions uniquely con^e^nds to a program 
parsed from a mutti-program data stream. 

The interface of daim 1, wherein the tuning seg- 
ment further comprises an increment graphic for 
incrementing the currently tuned program to the 
next highest available program. 

3. The interface of claim 1, wherein the tuning seg- 
ment further comprises a decrement graphic for 
decrementing the cun-ently tuned program to the 
next lowest available program. 

4. The interface of claim 1. wherein the number of 



programs available to a user. 
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. The interface of claim 1, wherein the tuning seg- 
ment further comprises a graphic slider overlaying 
the graphic bar and movable along the length of the 
tsar. 

Tlie interface of claim 5. wherein the position of the 
sfkler overlays and con-esponds to an underlying 
region frc»n the plurality of contiguous regions, the 
underlying regkwi co^esponding to the currently 
tuned program. 

The interface of daim 5, wherein the tuning seg- 
ment further conprises a program identification 
adjac^tothe slider. 

The interface of daim 7, wherein the program iden- 
tification comprises textual information related to 
the cunrently tuned program. 

The interface of claim 1 , further comprising a pop- 
up remote control graphic, the remote control 
graphic having a display and a plurality of graphic 
keys uniquely corresponding to a plurality of 
receiver station functions, the format and function- 
ality of the graphic keys and the display being asso- 
ciated with a current state of the interface. 

10. The interlace of daim 1, wherein the active 
video/audio segment conprises a substantial area 
portion of the first multi-segment display. 



11. 
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The interface of claim 1. furtiier comprising a serv- 
ice segment the service segment induding one or 
more service graphics representing links that 
launch the interlace into corresponding sub-groMps 
of interlinked service display states. 
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12. The interface of daim 1t» wherein the service 
graphics Include a graphic r^reserrting a link that 
launches the inlerfece into a sulhgroup of inter- 
linked service display states, the sul>^oiqF> of inter- 
linked service display states adapted to facflftate s 
the selection and display of video channels. 

13. TTie interlace of daim 11, wherein the servfce 
graphics indude a graphic representing a link that 
launches the interface into a sub-group of inter- io 
linked service display states, the 5ut>group of inter- 
linked service displs^ states adapted to facilitate 
the selection and d^tay of one or more w^>s(tes. 

14. The interfece of daim 13. further comprising: is 

one or more logos associated with the wet>- 
sites; 

a table stored in a computer memory and indic- 
ative of locally cached websites: 20 
a graphic cursor, the cursor being movable 
within the service display states; and 
a cache status overlay graphk:. the cache sta- 
tus graphic indicating the local cache status of 
a first website logo that is overiaid by the 2S 
graphic cursor. 

15. The interface of daim 11. wherein the swice 
graphics indude a graphic representing a link that 
launches the imerface into a subgroup of inter- 30 
linked service display states, the sub-group of inter- 
linked sennce display states adapted to facilitate 
the selection, display, and downloading of computer 
software. 

35 

16. The interface of daim 11, wherein the service 
graphics indude a graphic representing a link that 
launches the interface Into a sub-group of inter- 
linked service display states, the sut>-group of inter- 
linked sennce display states adapted to fadlrtate 40 
the selection, display, and downloading of nunteri- 
caldata 

17. The interface of daim 1 1 . wherein at least some of 
the subgroups of interlinked service display states 45 
and function display states are constructed in 
accordance with Information parsed from the multi- 
program data stream. 

18. The interface of claim 17. wherein the layout and so 
content of the service and function display states 
nfiay vary dynamically over time as a function of the 
infornf>ation parsed from the multi-program data 
stream. 

55 

19. The interface of claim 18. wherein the infonnation 
parsed from the multi-program data stream 
includes SDP + records. 



20. The interface of daim 1, further conprising a func- 
tbn segment the function segment indi^ng one or 
more function graphics r^esenting links that 
launch the interface into oorresponcfing sub-groi4>s 
of int^nked function display states. 

21. The interface of daim 20. wherein the function 
graphics irtdude a graphic representing a link that 
launches the interface into a sub-group of mter- 
linked function dispfay states, the sub-group of 
interlinked function dispfay states adapted to facOi- 
tate multi-day scheduling and review of program 
viewir^ and data downloading events. 

22. The interface of daim 20, wherein the function 
graphics indude a graphic r^esenting a ftnk that 
faunches the interface into a sub-group of inter- 
linked functim display states, the sut>-group of 
interlinked function display states adapted to facili- 
tate the setting of a satellite receiver statk>n's func- 
tion options. 

23. The interface of daim 20, wherein the function 
graphics include a graphic r^esenting a link that 
faunches the interface into a sub-group of inter- 
linked function display sfates. the sub-group of 
interlinked function dispfay states adapted to facOi- 
tate the selection and display of textual messages. 

24. The interface of daim 1. further comprising a title 
segment 

25 The interface of daim 1, further comprising a 
date/lime segment 

26. A method of selecting and dispfaying information 
transmitted in a digifal bitstream composed from a 
plurality of information data streams, comprising 
the steps of: 

parsing the digifal bitstream to extract a first 
information data stream from the plurality of 
information data streams; 
generating a graphic page layout arid organiza- 
tion in accordance with the first information 
data stream; 

parsing the digital bitstream to extract a second 
information data stream from the plurality of 
information dafa strjean^; 
generating a graphic page content in accord- 
ance with the second infonnation data stream; 
and 

displaying the graphic page content in accord- 
ance with the graphic page layout and organi- 
zation to produce a final graphic page display. 

27. The method of daim 26. wherein the layout, organ- 
ization, and content of the final graphic page display 
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may vary dynamicaOy over time. 

28. The method of claim 27, wherein the layout and 
organization of the final graphic page display is sub- 
stantially defined t)y SDP + records that are parsed s 
from the digital bitstream. 

29. The method of daim 26. further Including the steps 
of: 

JO 

receiving, from a user, an irput that is associ- 
ated with a particular saeen location within the 
final graphic page display: 
associating the particular screen location with 
a third infornration data stream from the plural- is 
ity of information data streams; 
parsing the third information data stream from 
the bitstream to form a user selected data 

displaying the user selected data stream. so 

30. The method of daim 29 wherein the particular 
screen location ties along a graphical tuning bar 
and portions of the tuning bar uniquely correspond 

to inlomiation data streams from the plurality of 2S 
information data streams, the particular screen 
location con-esponding to a particular portion of the 
tuning bar. the particular portion of the tuning bar 
corresponding to a particular infamation data 
stream. 3o 

31. The method of daim 30, wherein the particular 
information data stream corresponds to a TV chan- 
nel. 

35 

32. The method of claim 30, wherein the particular 
information data stream conresponds to a website. 

33. The method of claim 30, wherein the particular 
information data stream con-esponds to a data 4o 
channel. 

34. The method of daim 26, further induding the steps 
of: 

45 

receiving, from a user, an input associated with 
a particular saeen location within a context 
sensitive remote control graphic that overlays a 
portion of the final graphic page display; 
associating the particular screen location with so 
a receiver function; and 
invoking the receiver function within the 
receiver. 



a webpage logo, the webpage logo overlaying 
a portion of the final graphic page display and 
representing a link to webpage information; 
retrieving the webpage information associated 
with the webpage logo from a network; 
processing the webpage information into a web 
content information data stream; 
transmitting the web content data stream from 
a transmission station to a receiver station; 
receiving the web content data stream at the 
receiver station: 

processing the web content data stream at tiie 
receiver station to recover the webpage infor- 
mation; and 

storir^ the webpage information at the receiver 
station. 

36. The method of daim 35, wherein the step of 

receiver station comprises filtering the web content 
data stream. 

37. The method of daim 36. wherein the filtering is 
assodated with user specified criteria. 

38. The method of daim 36. wherein the filtering is 
assodated with predetermined aiteria. 

39. The method of daim 36, wherein the fWering is 
assodated with a SCID assigned at the transmis- 
sion station. 

4a The method of daim 35. wherein the network is the 
Internet. 

41. The method of daim 35, furtiier comprising the 
steps of: 

retrieving the stored webpage information; and 
displaying the stored wetipage information. 

42. The method of daim 41. wherein the webpage 
information is displayed in accordance with a 
graphical user interface. 



35. The method of daim 26, further induding tiie steps ss 
of: 



receiving, from a user, an input assodated with 
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Example Ticker SDP^ Record 
v=0 

o=DTV0001 17DSSIP4 
s= Announcement Ehimp 

c=DSS][P4 231. 17.43.6/1 
t=00 

m^data 3287 UDP SllUBAM 
a=k^:l 

a=nin:consoletidcer 
a^keywdsrtsetup 

FIG. 32A 



Example File Download SDP+ Record 

v=0 

o=DTV 0008 17 DSS IP4 

s=Data Catalog 

c=DSSP4 233.17.43.3/1 

1=3079382400 3155745600 

r=10m 10m 0 

m=data 3335 UDP BFDP 

a=k^:8 

a«fsz:980000 

a=mandatoiy 

a=nin:catalo^nstall.exe 

FIG. 32B 
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Example Webcast SDP+ Record 
v=0 

o=DTV900 17DSSIP4 
s=CNN 

i=Research finandal markets worldwide, get stack quotes^ and calculate your 

mortgage payments - all on-line. Read the "hot stories" of the week in the financial 

world. Complete listing of CNN's Fmandal Network television broadcasts. 

u=http://www.cnn.com/index.htm 

c=DSSIP4 233.17.43.7/1 

t=00 

m=data 3334 UDP WEBCAST 

a=cat:News 

a=key:900 

a=f5z:16000000 

a=display:type=l, priority=8 

a^mgxnn,^ 

FIG. 32C 



Example data enriched video SDP-)-.record 
v=0 

o=DTV0201 17DSSIP4 
s=GNBC 

c=DSS IP4 233.26.24.24/1 
t=0 0 

m=data 6500 UDP INTERCAST 

a=key:201 

a=channel:775 

FIG. 32D 
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